![](/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) |
>> The thing about a database is... the DBMS knows how to read the data.
>> And if you change how the data is stored (e.g., add a new field,
>> change a table from heap-organised to index-organised, etc.), as long
>> as the DBMS still knows how to read it, the client applications don't
>> need to *care*, and they don't break.
>
> Well, no. That's true of RDBMs, which is why they were revolutionary. It
> isn't true of database engines that were around before the relational
> model.
>
>> (Hell, if you add new fields or change the type of existing ones, you
>> can even create a "view" for the old apps to work off. They'll never
>> know the difference!)
>
> Yes. That was the amazingly cool thing about relational databases that
> you didn't get out of CODASYL databases or hierarchical databases or
> whatever.
Yeah, well, I have little concept of what other kinds of databases have
existed other than relational ones.
(We did hear some talk at uni about people working on object databases,
but nobody could really figure out precisely what such a term means...)
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 can also use "SQL Server Everywhere", which is Microsoft's SQL server
>> in a form that you link it into your program.
OK so that's changed name to SQL Server Compact Edition and seems to be the
pefect fit for what I need.
It's just a simple small download and install with no configuration needed,
and then from Visual Studio I can use a normal managed interface to create
and access a database. None of the messing about with installing server
services, service account, usernames passwords, horrible API interfaces etc,
it just works nicely out of the box and MS has lots of samples and tutorials
on how to use it :-)
Thanks, it has made my job a lot easier!
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) |
Invisible wrote:
> Yeah, well, I have little concept of what other kinds of databases have
> existed other than relational ones.
Relational pretty much replaced *everything*, and then along came OODBs and
along came distributed databases.
> (We did hear some talk at uni about people working on object databases,
> but nobody could really figure out precisely what such a term means...)
It means it doesn't follow the relational model, but instead the OO model.
For example, say you're using an OO language. (I'll assume you know how OO
languages work.) At some point, you say "stick this object in the database."
It says "OK." Then you can exit. When you start up again, that object is
still around, as well as anything it had pointers to in member variables.
It's nice because you can stick big blobs of data in and efficiently fetch
and store it all at once. So something like "my facebook account" would be
one record, or "this wiki page with all the history, embedded images, etc",
or Amazon with "this product, all its pictures, descriptions, reviews,
keywords, tags, etc". When much of your work is with one large record, you
can fetch it, use it, and put it back with relatively little overhead
compared to the RDBM.
The hard part is when you want to do something like (say) add up the amount
of money in all outstanding shopping carts, and you have to figure out how
to iterate over the objects without sucking the entire user's account into
memory for each one. If you can fit one entire table into memory, this is
less of a problem, but obviously still not trivial.
The advantage of an OODB is that you don't have to write a lot of code to
deal with format changes between what you store on disk and what you store
in memory. The disadvantage is that the only easy way to get to it is
usually the way it's stored in memory.
--
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) |
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.
--
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) |
>> Yeah, well, I have little concept of what other kinds of databases
>> have existed other than relational ones.
>
> Relational pretty much replaced *everything*
Yeah, I get that part.
>> (We did hear some talk at uni about people working on object
>> databases, but nobody could really figure out precisely what such a
>> term means...)
>
> It means it doesn't follow the relational model, but instead the OO
> model. For example, say you're using an OO language. (I'll assume you
> know how OO languages work.) At some point, you say "stick this object
> in the database." It says "OK." Then you can exit. When you start up
> again, that object is still around, as well as anything it had pointers
> to in member variables.
>
> It's nice because you can stick big blobs of data in and efficiently
> fetch and store it all at once. So something like "my facebook account"
> would be one record, or "this wiki page with all the history, embedded
> images, etc", or Amazon with "this product, all its pictures,
> descriptions, reviews, keywords, tags, etc". When much of your work is
> with one large record, you can fetch it, use it, and put it back with
> relatively little overhead compared to the RDBM.
>
> The hard part is when you want to do something like (say) add up the
> amount of money in all outstanding shopping carts, and you have to
> figure out how to iterate over the objects without sucking the entire
> user's account into memory for each one. If you can fit one entire table
> into memory, this is less of a problem, but obviously still not trivial.
>
> The advantage of an OODB is that you don't have to write a lot of code
> to deal with format changes between what you store on disk and what you
> store in memory. The disadvantage is that the only easy way to get to it
> is usually the way it's stored in memory.
Now, see, from what I could tell, everybody has their own idea about
what an OODBMS actually "is". You say it follows the "object model", but
people don't seem to be able to agree on precisely what that is.
As it happens, during my degree we had to do a "research project". The
idea was to come up with a topic, "research it" (whatever the hell that
means) and then write something about it. (Needless to say, I failed
badly at this.) The topic I was given was "the object-relational
impedence mismatch".
It seems that basically it's possible to encode objects into the
relational model without too much difficulty. What an OODB gives you is
the ability to store stuff without all that pesky marshalling. On the
other hand, it appears you lose any ability to query the database.
In other words, you save a little bit of code, and lose almost
everything that makes databases useful. Which seems like a very, very
unfavourable compromise.
Unrelated, but... it seems, intuitively, that functional programs should
be a much better "fit" to the relational model.
--
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:
> 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) |