On 08/02/2012 03:46 PM, Richard Pieri wrote:
On 8/2/2012 12:50 PM, Mark Woodward wrote:
This is incorrect. No system with more than one of anything can
consistently get O(1). There has to be some way of getting a
specific
I'll touch on this point down below.
That is your opinion, you are welcome to have it, but if you want to
debate, put up some arguments to assert the veracity of your
assertions. If you question my decisions, that's fine, but make sure
you back up your statements with facts that can be debated,
otherwise it is just a personal insult.
The largest example I can think of is the VA Hospital system. It uses
an object database for record keeping for some 8 million veterans.
Delivered early and under budget, by the way.
Not to be snide, but 8 million is not a big number.
A little smaller is Partners Healthcare here in Boston. My knowledge is
a little out of date on this but they were looking at deploying a system
for over 30K users across all of the hospitals in town.
OK
One that I'm more directly familiar with is Ameritrade. I watched
Ameritrade's conversion from Oracle to Cache for their customer-facing
applications. Why? Because Oracle couldn't keep up with their trading
load. Billions of transactions per day. Oracle couldn't keep up; the
database cluster kept crashing.
Well, "billions" of transactions per day should be doable in a cluster.
If your oracle database is crashing, it is misconfigured. Financial
transactions are a dangerous thing, you really do need ACID for
fiduciary responsibility.
You are conflating database structure with nomenclature. Under any
storage system, there is data management. Classes and inheritance do
not magically do anything. You must code version migration to
successive versions. This may be merely pre-initializing member
variables, but it has to be done none the less.
No, I'm not. It's one of the beautiful things about object databases.
It's the same as object-oriented programming: you build your classes
and let inheritance organize data. In the cases where you need to
provide assistance you incorporate that logic as a method.
You are avoiding the topic, the "storage system," is separate from the
implementation of the objects. The objects know how to serialize and
restore themselves as well as upgrade. The storage and location of
objects is not involved.
It's great that Oracle, et.al., provide means of doing it but
you're still constrained by the relational model.
How?
Relational tables.
That is not a "how," it is a adjective and a plural noun. One does not
need to use relations in a database, but one has them if they need them.
An RDBMS is a tool not some kind of mandate.
How? How does one "nest" in an object store? An object, once
instantiated, instantiates another object. Why does this not work.
The object has hierarchical data? That's in the XML/JSON. Any
generic object management system with any specific object
implementation needs to work out these relationships.
You don't instantiate two objects; you instantiate an object with a
sub-object as one of its elements. It's basic OOP design.
Yes, ok, that is done with the XML/JSON class description. What's the
problem?
This is nonsense. Seriously. I have a table:
This is my point: you have a table. The table is a kind of object but
everything in a relational database is defined in terms of or in
relation to tables. So what you have is not an XML object; it's a table
with an XML object stored in one of its cells.
You are confusing the SQL language with data storage. In postgreSQL, for
instance, a "table" is nothing more than file filled with variable
length objects. Its called a table out of canonical usage. You are
mistaking a semantic difference with a technical one.
If I said the XML was stored in a binary polymorphic object file and it
could be retrieved by its ID, would that make a difference? Because,
that is exactly what is happening. For convenience, we call the the
polymorphic object file a "table."
The best part is that, in postgresql, I can index on fields within
the object to find an object based on the value of a property. Can
your object store do that? No.
Object databases don't need this kind of indexing. You reference data
by Object.Sub-object.Slot.data. This is how object databases deliver
consistent O(1) performance.
Sorry, no. It is either a hash table, or they are hiding the index from
you. Either way, it doesn't matter because databases have hash indexes.
And if you say that objects don't need that kind of indexing, then you
miss the real power of database. If you have 8 million objects, say
patients in a database. How do you find them by social security numbers?
How about by last name? How about by symptoms?
Information is not a static thing. It needs to be usable to be valuable.
Well, yes, I could make a cycle with 5 wheels, but there are
conventions.
Screw conventions. If a 5-wheel cycle is what you need to make your
application work better then make a 5-wheel cycle.
"8-bit clean" you mean the data stream need to be UTF-8, correct?
I mean that if you put arbitrary 8-bit (binary) data in then you must
get the same 8-bit data out.
Ok, then sure, that's to be expected. What you put into a database is
what you get out, that is, quite frankly, what a database does. I do not
understand the point you were trying to make.
Exactly. So what advantage does your data store have over an RDBMS
when and RDBMS can do anything your data store can do?
Better performance,
How? Prove it.
greater scalability,
How? Prove it.
faster deployment,
How? Prove it
easier
maintenance,
How? Prove it
and typically at a lower cost for all of it.
PostgreSQL is free. It doesn't get much lower in cost.
I don't know about you, but I use a database for my domain DNS
servers, yes postgresql. Its actually two tables, the domain entry
table and the hosts table. I have a web administration package for
it and I use replication to copy changes. It works great.
If I may make a joke: I suppose it is tempting, if the only tool you
have is PostgreSQL, to treat everything as if it were a table. Which
brings me back to the start:
No, I needed a DNS system that could replicate, allow user access,
managed rights and privileges, etc. I could coble something together, or
use a package that worked out of the package. It was a no brainer.
Big data has its own issues, this is true. You haven't said how or
why any one system is better than any other here.
Your DNS system is not proof. It's confirmation bias.
Not really, the DNS package was part of a bigger project that included
firewall hole punching, dynamic DNS, VPN, etc. I just used it.
You have
expertise in deploying PostgreSQL applications and here's an example of
one of your PostgreSQL applications working well.
I do have some expertise in PostgreSQL, sure, but I always try to find
the best tool for the task. I have used SQLite and I have done a fair
amount of storage systems where an RDBMS is not appropriate.
I have have a flat
text file that I edit with Emacs, and I have a Makefile to validate the
file and generate reverse zones. It works great and it doesn't require
the overhead of a database and web server. This is confirmation bias,
too.
Well, that wasn't acceptable for the task at hand as I have explained.
_______________________________________________
Discuss mailing list
Discuss@blu.org
http://lists.blu.org/mailman/listinfo/discuss
