user’s data is naturally something
other than tables and if simulating his natural data model on top of
tables is awkward, then chances are
that a native implementation of the
natural data model will significantly
outperform a conventional relational
DBMS. This is certainly true in scientific data.
A different implementation of tables. If something other than a row store
accelerates the user’s queries, then a direct implementation of the relational
model using non-row store technology will run circles around a conventional relational DBMS. This is true in
the data warehouse marketplace.
A different implementation of
transactions. Current row stores give
you a “one size fits all” implementation
of transactions. This can be radically
beaten if a user has lesser requirements
or if the system can take advantage of
workload-specific features. This is true
in the OLTP marketplace.
One of these characteristics is true
in every market I can think of. Hence,
in my opinion, the days of a “one size
fits all” monolithic DBMS are at an end.
The replacement will be a collection of
vertical market-specific engines, with
much higher performance.
You might ask, “What if I don’t care
about performance?” The answer:
Run one of the open source relational DBMSs. They are mature, reliable,
and, best of all, free.
You might also ask, “I am dug in
deep with my current vendor(s). What
do I do?” The answer: Take some portion of your DBMS budget and allocate
it to new solutions. Over time, you will
move onto better technology.
It is very true that relational DBMSs
are overhyped for not so valid reasons.
The current trends also showcase that
there are viable alternatives to relational
DBMSs, which can beat them at their own
game. Also, the emergence of distributed
key-value stores, such as Cassandra and
Voldemort, proves the efficiency and cost
effectiveness of their approaches.
Also, the recently concluded NoSQL
conference discussed at length how
distributed, non-relational databases
work, along with overview of the emerging
alternatives in this space.
Pavan Yara —
from Jason hong’s
interfaces for usable
Privacy and Security”
I often cringe when I hear
highly technical engineers talk about people.
I usually hear broad generalizations
tossed about, like “people are lazy,
that’s why they can’t use the system”
or “people don’t understand security.”
The worst is “people are just stupid.”
With this kind of attitude, it’s no
surprise there are so many complicated
user interfaces in the world, let alone
in privacy and security. Failing to try
to understand things from the user’s
point of view is the cardinal sin in user
With this in mind, I thought it
would be good to shift focus in this
blog entry away from individual case
studies of usable privacy and security,
and look at the bigger picture of how
to design better user interfaces.
Now, how to craft an effective user
interface is a very involved topic that
one can study for years, and there are
lots of great Web sites and books out
there. Effective user interface design
combines our understanding of aesthetics, technology, and human behavior to develop artifacts that are useful,
usable, and desirable for a specific target audience.
What makes usable privacy and
security different from designing
other interfaces is that privacy and
security are often secondary tasks.
People don’t go to an e-commerce
site explicitly wanting to protect
their credit cards and email addresses; they go there to buy things. Security and privacy are obvious things
they want while accomplishing their
main goal, in the same manner that
they want the Web site to also be fast
Roughly, there are three broad strategies for usable privacy and security
(note that these aren’t mutually exclusive):
make the interface invisible ˲
make the interface more under- ˲
train the users ˲
A good example of better security
by making the interface invisible is
Secure Sockets Layer. End users don’t
have to do anything special, and all
of their network traffic is transparently encrypted.
Oftentimes, we just need to make
the user interface more understandable to end users. This might be accomplished through better layout, simplified task flows, better visualizations,
or more appropriate metaphors (why
do we sign digital documents using
Finally, some user interfaces may
also require training the users. One
common misconception about user
interfaces is that they should be “
intuitive” (a description that always raises
a red flag with me). If you’re a Star
Trek fan like I am, you might remember that famous scene in Star Trek IV
where Montgomery Scott, the ship’s
engineer, tries to use a Macintosh
computer. After attempting to talk to
the computer and getting no response,
he picks up the mouse and tries talking into it. Intuitive indeed.
Applications are always designed
for a specific context, for specific purposes, and for a specific target audience. The best designs will empower
people and let them get started quickly, while also providing a way for them
to get better.
As such, some applications will
require some level of training. The
training might range from a basic understanding of how to zoom in and out
on the iPhone (which Apple cleverly
trained people how to do, with their
television ads), all the way to learning
how to drive a car (something we actually start training our children to do
since birth, given how ingrained cars
are in society).
Now, this doesn’t mean that you
can get away with a disastrous user
interface and expect people to have to
train how to use it, but it also doesn’t
mean that all user interfaces should
be walk up and use either. You have
to balance ease-of-use with power and
flexibility for your specific audience and
your specific goals. As Silicon Valley
pioneer Doug Engelbart once noted, if
ease of use was all that mattered, we’d
all still be riding tricycles.
Michael Stonebraker is an adjunct professor at the
Massachusetts Institute of Technology. Jason hong is
an assistant professor at Carnegie Mellon University.