 |
 |
|
 |
|
 |
|  |
|  |
|
 |
|
 |
|  |
|  |
|
 |
>> You mean like the way SQL is more scalable *because* you can't process
>> the next row depending on what the previous one was?
>
> Basically, yes.
Mmm, OK.
> In order for SQL to maintain the consistency guarantees,
> it has to have access to all the data. If you don't want duplicate
> primary keys, at some point, your primary keys have to all be on the
> same computer.
Not necessarily. If you partition all the PKs into buckets and each
bucket resides in a single place, you can still check for duplicates.
> If you have 5 TB of primary key information in one table,
> you have trouble.
Yes. For a start, where do you find enough physical space to put that
many HDs to store it all?
> 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. ;-)
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.
>> Of course, trouble is, almost all Haskell libraries that involve C
>> fail to compile on Windoze. (I'm told it's because Windows lacks a
>> "standard" place to put header files, etc.)
>
> Uh, well, it means there might be more than one compiler. :-) I thought
> the idea was to use compiler switches for that. :-)
It seems that on Linux, Haskell's package manager somehow automatically
detects if the C library is installed, and if so, where it can be found.
On Windoze, however, it tends to just spaz out.
OTOH, it's not unheard of for Haskell packages to use bash scripts as
part of their build process, so...
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
 |
|  |
|  |
|
 |
|
 |
|  |
|  |
|
 |
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
|
 |
|  |
|  |
|
 |
|
 |
|  |
|  |
|
 |
> Glad to help! :-)
You won't be saying that when I come back with 100 SQL questions next week
:-) I think I will get a book though as my knowledge is a bit fragmented
and I'm probably doing things the wrong way - that's the worst, people who
think they know what they are doing but really they have no clue :-)
> Note there are similar things on the other major OSes, but I don't recall
> what they're called nowadays.
Nah it's ok, my program is to work alongside another data collection program
that is windows-only (actually it looks like it is for Windows 3.1 but works
under Vista, amazingly!).
Post a reply to this message
|
 |
|  |
|  |
|
 |
|
 |
|  |
|  |
|
 |
scott wrote:
> Got that all working now - at some later date I will need to figure out
> how to install postgres silently with all the correct options so my app
> will run
> without having to explain to the user how to install it. And then cope
> with what happens when postgres is already installed...
I think there is an embedded Postgres so you link it with your app, instead
of running it as a separate process and connecting to it.
Or you could use SQLite instead, which is specifically made for embedding :)
Post a reply to this message
|
 |
|  |
|  |
|
 |
|
 |
|  |
|  |
|
 |
Orchid XP v8 wrote:
> 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.
You should stop saying "this is obviously impossible". Especially when you
have seen it work in the real world (so it's obviously not impossible).
</Warp-impersonation>
Post a reply to this message
|
 |
|  |
|  |
|
 |
|
 |
|  |
|
 |