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

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

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

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

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

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