|
 |
Orchid XP v8 wrote:
> Not necessarily. If you partition all the PKs into buckets and each
> bucket resides in a single place, you can still check for duplicates.
And that's basically what the other systems do. An RDBM calls that
"sharding". It works until you need to do a join, or you have a FK
constraint. And it only works as long as the other data associated with that
record is in the same shard.
In other words, if you do this with customers, and you do this with orders,
and you do this with products, getting the list of customers who buy the
most different kinds of products goes to its knees.
> Yes. For a start, where do you find enough physical space to put that
> many HDs to store it all?
Err, I have two 3TB drives plugged into my machine right now. (Doing
backups.) A terabyte is no longer big. It's a standard size drive.
>> You already use an OODB every day. It's called a file system.
>> You can't do complex searches.
>
> That's why people use database engines when they want stuff to be
> searchable. ;-)
Yep. More specifically, they use something indexable. You can do this with a
file system - you just have to keep the index up to date.
And when you change a file, you will have some number of seconds between
closing the file and creating the index that points to that file for each
word, and in that time a search won't find that document. And *that* is
exactly the kind of inconsistency you don't want with a SQL database. See?
> Still, I guess even an OODB can be indexed... Google somehow manages to
> find all the webpages in the world that contain the word "banana" in
> less than 1000 ms, even though this is obviously impossible.
It's less hard when you just throw hardware at the problem. :-)
> OTOH, it's not unheard of for Haskell packages to use bash scripts as
> part of their build process, so...
That'll slow you down, yes.
--
Darren New, San Diego CA, USA (PST)
"Ouch ouch ouch!"
"What's wrong? Noodles too hot?"
"No, I have Chopstick Tunnel Syndrome."
Post a reply to this message
|
|
