![](/i/fill.gif) |
![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
>> 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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
>> 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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
> 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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |