 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Darren New wrote:
> scott wrote:
>> I just need to revise some SQL now and first of all work out how to
>> create databases and tables from my code.
>
> You do it with SQL.
Incidentally, for history buffs, that was one of the three or four
revolutionary amazing-at-the-time things that the relational model
introduced: the metadata of the data is accessible as data. That hit the
data world the way von Neumann architecture hit the electrical engineering
world. :-)
(The others being a mathematically rigorous foundation, a lack of pointers,
and separation of modeling concerns from efficiency concerns, all of which
were astoundingly revolutionary at the time.)
--
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Darren New wrote:
> Incidentally, for history buffs, that was one of the three or four
> revolutionary amazing-at-the-time things that the relational model
> introduced: the metadata of the data is accessible as data. That hit the
> data world the way von Neumann architecture hit the electrical
> engineering world. :-)
>
> (The others being a mathematically rigorous foundation, a lack of
> pointers, and separation of modeling concerns from efficiency concerns,
> all of which were astoundingly revolutionary at the time.)
The way I heard it, before databases came along, if you had a dozen
programs that all accessed the same pot of data, they all had to
understand the same file format. And if you *changed* that file format,
all your programs broke - usually be silently producing gibberish
instead of real data. Then you'd have to go modify them all one by one
to fix them.
Story goes that one company changed their file format so that some of
their bills to customers contained gibberish which actually leaked
information about their supplier relationships. A competetor got hold of
this information, managed to figure out what the gibberish was, and
managed to gain a competetive advantage.
(Nice story, but sounds kinda made-up to prove a point to me...)
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.
(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!)
At least, that's the PoV I got. I wasn't there, so...
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Orchid XP v8 wrote:
> The way I heard it, before databases came along, if you had a dozen
> programs that all accessed the same pot of data, they all had to
> understand the same file format. And if you *changed* that file format,
> all your programs broke - usually be silently producing gibberish
> instead of real data. Then you'd have to go modify them all one by one
> to fix them.
Well, yes.
> 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.
--
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 do it with SQL. Probably something along the lines of
>
> CREATE DATABASE mystuff;
>
> CREATE TABLE mytable (
> somenumber INTEGER NOT NULL,
> comestring VARCHAR(50) DEFAULT '',
> primary key somenumber
> );
>
> Look up those keywords.
OK thanks that's certainly a good start, I've never worked with creating
this stuff from scratch before.
> You'll also need to figure out how to connect in the first place. Grep the
> manual for "connection string", which is usually how it's described. It
> tells basically the address of the server (IP & port, usually) plus user
> plus password.
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...
> Warp wrote:
> > If you need to output the data in some special format, after it has
> > been
> > processed, I really don't know what tools, if any, SQL offers for this.
>
> SQL doesn't offer too many tools as such, i.e., not in a portable way.
Most of the "results" I will just be using to display tables or graphs
within my app.
> You could also use metakit (from equi4.com) if you want a nice embeddable
> database that isn't SQL (it's not even normalized). Just a plug for a
> great product.
Will take a look, thanks.
> You can also use "SQL Server Everywhere", which is Microsoft's SQL server
> in a form that you link it into your program.
Ditto.
> PHP is OK for doing database stuff, but it's kludgey, so if you expect the
> system to grow, or other people to work on it, it's probably something to
> stay away from unless you need it for some other reason anyway. It's a way
> to quickly hack together web front ends, and its use as a desktop tool is
> poor.
THere are certain other parts of my code that need to be run pretty quickly
(some simulation stuff) and as I already have a lot of that in C++ I think
my best bet is to find the best database backend to use from C++.
What I might do is write a wrapper class for the database parts of my code
that will initially just use simple STL structures to store/retrieve/filter
data and then later I can write code to use a db engine instead once I get
it working with small datasets.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
scott wrote:
> What I might do is write a wrapper class for the database parts of my
> code that will initially just use simple STL structures to
> store/retrieve/filter data and then later I can write code to use a db
> engine instead once I get it working with small datasets.
Heh. That's pretty much exactly what the LINQ stuff in the .NET packages
does. An XML file looks like a SQL server at the source code - you just
build a different db connection object at the beginning.
If you're going to be filtering your own values anyway, look into the
non-SQL databases like metakit. The primary advantage of the SQL databases
is you can write expressions in SQL that manipulate an entire table (like
finding the max, min, average and sum of a whole column) in one statement.
If you're going to do that yourself anyway, it's probably easier to have the
code linked into your app than it is to try to install postgress but only if
it's already not installed *or* if you have permission to use it, etc. :-)
--
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> 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
|
|
| |
| |
|
|
|
|
| |
|
|
