Orchid XP v8 wrote:
> In other words, you save a little bit of code, and lose almost 
> everything that makes databases useful. 

You can gain performance in certain circumstances. For example, if you look 
at "memcached", it's basically an OO database that serves as a front end to 
relational databases, except you have to manage it manually. An OODB for the 
right problem can be much more scalable *because* you lose the ability to 
search.

> Unrelated, but... it seems, intuitively, that functional programs should 
> be a much better "fit" to the relational model.

Yeah. I was thinking that. Imagine STM monoid values that don't disappear 
when your program exits, for example. Sort of the same idea...

-- 
   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

>> In other words, you save a little bit of code, and lose almost 
>> everything that makes databases useful. 
> 
> An OODB for the right problem can be much more scalable 
> *because* you lose the ability to search.

You mean like the way SQL is more scalable *because* you can't process 
the next row depending on what the previous one was?

>> Unrelated, but... it seems, intuitively, that functional programs 
>> should be a much better "fit" to the relational model.
> 
> Yeah. I was thinking that. Imagine STM monoid values that don't 
> disappear when your program exits, for example. Sort of the same idea...

Yeah, that could work...

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.)

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

Darren New wrote:
> scott wrote:
>> Thanks, it has made my job a lot easier!
> 
> Glad to help! :-)
> 
> Note there are similar things on the other major OSes, but I don't 
> recall what they're called nowadays. Shouldn't be too hard to find if 
> you ever wind up working under Linux or something.
> 

SQLite maybe ?

http://www.sqlite.org/

-- 
Vincent

Post a reply to this message

Orchid XP v8 wrote:
> 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. 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. 
If you have 5 TB of primary key information in one table, you have trouble.

You already use an OODB every day. You store your web pages on it. It's 
called a file system.  You can't do complex searches. You can't find all 
your Word documents that refer to a particular piece of lab equipment, for 
example, without actually reading all the Word documents. But it *does* let 
you store both programs and documents in the same system, for example.

(OK, it's not quite OO, but it's not relational, which is my point.)

> 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. :-)

-- 
   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

Vincent Le Chevalier wrote:
> SQLite maybe ?
> http://www.sqlite.org/

That's one, yes. I think Sun had one, and at one time "mSQL" was similar 
too, but I see that has gotten closed up since I last looked at it.

-- 
   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

>> 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