On 08/02/2012 12:02 PM, Richard Pieri wrote:
On 8/1/2012 11:33 PM, Mark Woodward wrote:
This is quite wrong. Seriously. If it is a simple "select * from
table where val = 'foo;" Then, if there is no index, it will be a
table scan. If you execute "create index table_val on table (val)"
then you will create an index that will give you (typically) O(log
n)
Oracle, et.al. have put a great deal of effort into optimizing
tables. They've moved from O(n) to O(log n). Still slow. Object
databases are typically O(1). No relational database can match that.
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
object from a store. The only way O(1) can work is if they are stored
in a large hash table and it is easy to exceed the usable amount of RAM
in a system with a big enough data store. When that happens you have I/O
and file system access. Your addressing may look like O(1), but the
access of an object will likely be O(log N) on file system access.
And yes, Oracle and PostgreSQL do have hash indexing if you want to use it.
Seriously? How much data are you talking about before it "slows to an
unusable crawl and maybe the system crashes?"
That depends on how much hardware you throw at it. Even Oracle's
Exadata frames will crash and burn if you overload them. It's awfully
hard to do that but it has happened.
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.
I actually wrote a DICOM image server using early Postgres95. BTW. Do
those count as medical records?
I'm not suggesting that you can't build medical applications with
tables. I am suggesting that there are vastly superior alternatives
available and questioning your reasons for avoiding them.
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.
Well "versioning" is kind of complex, versioning of the object itself
or the contents?
Either, both, take your pick. Even if the engine doesn't directly
support versioning it can be implemented with classes and inheritance.
And you won't suffer the performance hit that you would with replicating
rows in tables.
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.
One of my favorite constructs is an XML or JSON column in a table.
How is this not an object?
This demonstrates my point.
Not really.
If tables were superior to objects then
there would be no benefit to stuffing XML or JSON into table cells.
That is a silly argument. An RDBMS is meant to handle "data." There is
no law or practice that says data can't be an object. You are trying to
assert a conflict that does not exist.
It's great that Oracle, et.al., provide means of doing it but you're
still constrained by the relational model.
How?
They're not really nested if
they're columns in a table.
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.
If you used an object database instead of a
relational database then you could define or modify an appropriate
class to encapsulate your XML or JSON objects.
This is nonsense. Seriously. I have a table:
create table myobjects(objectid int, object xml_type);
How is this not (a) valid or (b) legal?
Now, I have used this very structure in Java and PHP web sites using my
own extension in PHP and XStream in Java for years. The objects manage
themselves.
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.
Most RDBMS these days have support for XML or JSON, hell you could
serialize binary objects from C or C++ into a blob if you are
insistent about binary objects, but none of the "object" databases
support binary objects, per se'
Because it's unnecessary. Objects are arbitrary. You can construct
them however you like.
Well, yes, I could make a cycle with 5 wheels, but there are conventions.
The only requirement for the engine is to be
8-bit clean.
"8-bit clean" you mean the data stream need to be UTF-8, correct?
This goes for any storage system, not just database
engines.
Exactly. So what advantage does your data store have over an RDBMS when
and RDBMS can do anything your data store can do?
As for DNS, yes, any given zone can be implemented as a table. But the
whole of DNS isn't a table. It's a hierarchy of objects.
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.
_______________________________________________
Discuss mailing list
[email protected]
http://lists.blu.org/mailman/listinfo/discuss
