Archived

This topic is now archived and is closed to further replies.

EvilCrap

data bases

Recommended Posts

hi im n a relational database class (3 actually), and i feel that relational databases are extremely stupid and crappy, compared to how i might design a db in c++. my teachers keep mentioning object based databases - although i havent studied any, i think i got an idea of what the syntax differences would be -but are there any functional/implimentation differences? if there are, then maybe my problems with rdb are solved.

Share this post


Link to post
Share on other sites
Yes there is (I''ll come back to this). And no relational database aren''t stupid.

They not only work in C++ but almost any languages. These are very sophisticated piece of software. All the paging/caching, query optimizer, index management, etc would be very hard for you to write. : )

Object database usually stores object. : ) In fact you don''t have a concept of table and such. No object <-> relational mapping too. I worked with Gemstone (OO database for Smalltalk) for 2 years in the past. So instead of creating a table, you create a container which is a class. It could be based on STL implementation by example. Depending of your need for this table you may choose different container (vector, map, etc). In Gemstone smalltalk we where mostly using Dictionary (std::map in C++).

To add an object to a collection you just start a transaction (as you would in a relational database) and inserts your object in the container. No SQL. Just a statement like clients[100] = new Customer("Patrick"); When you commit the transaction, a new Customer is persisted in the OO database. It simplifies a lot database access.

But not everything is beautiful: you may suffer from performance problem (as you could from a relational system) and Gemstone had a limit of 1,000,000,000 objects in the database. It seems a lot, but when you know that a String is an object, etc.. then it adds up really fast! This was a Gemstone limit tough I don''t know for other OO databases.

All in all, it''s very easy to work with object database as it is really straightforward. But most companies cannot use them because they invested so much in relational database (I work mostly for government agencies as a freelancer).

Patrick Lafleur

System Engineer
Creation Objet Inc.

Share this post


Link to post
Share on other sites
hmmm, I've been coding against RDB technology, in one form or another, for about 12 years, I can't say that the words stupid and crappy turn up very often in my use of RDB's.

But I am prepared to bow to your extensive knowledge in this field, if you do the decent thing and actually explain why you find the technology limiting, or is it you just can't be bothered to learn the stuff properly ?

P.S. Please do post your revolutionary designs for a database, I could do with a good laugh.


Edited by - MonkeyChuff on January 30, 2002 4:13:32 AM

Share this post


Link to post
Share on other sites
OODBs have some major problems:

Lack of standard querying language (although I think this is being fixed will an upcoming version of SQL)
Lack of design process - with a relational database you build some tables and normalise them, no equivalent process with OO databases.
No built in integrity checking - each object has to handle its own integrity checking.
No standard navigation - can't just follow relationship links between tables, have to figure out links between objects at run time and follow them.

Yes, I have just done an exam in Database Systems!

If any of this is wrong then I apologise - blame my lecturers!

Enigma
------
...the thought that we have an...

Edited by - Enigma on January 30, 2002 6:54:30 AM

Share this post


Link to post
Share on other sites
I would say, that using something like Enterprise JAVA Beans and relational databases meets somewhere in the middle for both...

Something like an Enterprise JAVA Entity Bean lets you represent a row or orws of a atable as an object. These so called Beans handle all the transaction stuff for you etc...

Share this post


Link to post
Share on other sites
-i never said i would attempt to write a db, i said design.

-dont bother to learn stuff properly? -i know what my proffessors have lectured about.
-my ideas are applicable then they certainly arent revolutionary.

my problems are mainly the implimentation im assuming from the sql interface. i havent yet studied literal memroy/structure implimetation, so i may be misleaded.

let me break down my view of a table.
a table is basically an array of elements, where an element has specific attributes, like name, age, etc. elements also have keys, or special data posessed by elements in other tables -a table can relate to elements in another table via a key.

the problem is that keys are specific to elements, therefore they can get vastly duplicated in relations like one-to-many, where one table will contain many elements with duplicate keys relating to a primary key table. this is horrid.

wouldnt it be faster and more memory effecient to have keys that can point to tables? thisaway, i can have a customer table where each customer has a specific order table, instead of customers relating to a single order table. - the jumps between data would be decreased a ton. (if linked lists are used, and even more if complete redim is used). querying orders without going through customers could be dont by a collection table, maintaining all order tables.
ofcourse, there would be times when you dont want to do this, therefore you should be able to design the structure of how ur tables can relate, at an implimentation level.(can pl-sql do this?)

the problem is pointers!! there are no poitners!!

-lack of design process? -what ever happend to uml?

Share this post


Link to post
Share on other sites
quote:
Original post by EvilCrap
-i never said i would attempt to write a db, i said design.

-dont bother to learn stuff properly? -i know what my proffessors have lectured about.
-my ideas are applicable then they certainly arent revolutionary.

my problems are mainly the implimentation im assuming from the sql interface. i havent yet studied literal memroy/structure implimetation, so i may be misleaded.

let me break down my view of a table.
a table is basically an array of elements, where an element has specific attributes, like name, age, etc. elements also have keys, or special data posessed by elements in other tables -a table can relate to elements in another table via a key.

the problem is that keys are specific to elements, therefore they can get vastly duplicated in relations like one-to-many, where one table will contain many elements with duplicate keys relating to a primary key table. this is horrid.

wouldnt it be faster and more memory effecient to have keys that can point to tables? thisaway, i can have a customer table where each customer has a specific order table, instead of customers relating to a single order table. - the jumps between data would be decreased a ton. (if linked lists are used, and even more if complete redim is used). querying orders without going through customers could be dont by a collection table, maintaining all order tables.
ofcourse, there would be times when you dont want to do this, therefore you should be able to design the structure of how ur tables can relate, at an implimentation level.(can pl-sql do this?)

the problem is pointers!! there are no poitners!!

-lack of design process? -what ever happend to uml?


Definitely not an expert here, but I believe that each customer having their own order table would be hard to realize in current RDBMS'. And even if you were able to set that up and have it work, I would believe that while retrieving information for specific customers and their orders would be faster, what happens when you need to cross reference all orders from a large list of customers and pull information that is going to be related to more than one customer. The lookup speed is decreased at that level I'd assume because instead of hunting in one indexed field in each of 2 tables it has to branch out to a different table for every customer's orders and THEN traverse the index of each of those.

< edit > changed increased to decreased and corrected a couple of grammar/spelling errors...

Edited by - wrenhal on January 30, 2002 2:58:10 PM

Share this post


Link to post
Share on other sites
im not talking about rdb, u cant impliment it in any rdb i know.
it might not be faster in all cases, but you can predict what queries will be most frequent.

and its not a *complete* idea, there are ways to optimise it for specific purposes.

Share this post


Link to post
Share on other sites
quote:
Original post by EvilCrap
im not talking about rdb, u cant impliment it in any rdb i know.
it might not be faster in all cases, but you can predict what queries will be most frequent.

and its not a *complete* idea, there are ways to optimise it for specific purposes.


That''s what I know most about though. I personally have looked a bit at some of the OO stuff, but I think that''s more to appeal to programmers and jump on the OO band wagon. It seems to me that RDB is more flexible and user-friendly than the OO design. Of course designing and behind the scenes stuff seems pretty good with the OO design, but what I mean is front end wise for the user to find information in the database. with RDB I feel it''s easier to find info in the DB without having a deep knowledge of the underlying structure.

Share this post


Link to post
Share on other sites
First off, realize the RDBs dominate the database market. I would venture to say that in commercial use, nearly all systems that require a database today use a relational database. Billions have been poured into the development of RDB technology by the likes of Oracle, IBM, MSFT, Sybase, etc. Database experts are in high demand, and demand high salaries. RDBs show no sign of abating or diminishing in importance.

That said, let''s talk a little about how to use them.

In table design, you can either have ''normalized'' or ''denormalized'' tables. A ''normalized'' table design will minimize the amount of duplicated data by using separate tables to model portions of the data that may be reused by multiple objects. A ''denormalized'' table design minimizes the number of tables at cost of possible duplication of data.

For example, a customer table schema in a normalized database might consist of a number of tables: ''main'' customer table, state/province table, products used table, etc. The main customer table then contains ''pointers'' into the other tables as necessary (''keys'' in RDB terminology). In a denormalized schema, there might be only one customer table, with duplicated data for the state/province column, etc.

''Pointers'' are possible in RDB, and can take a number of forms. You can have a ''natural'' key where the combination of one or more columns forms a ''pointer'' into another table. Or, you can make an ''artificial'' pointer by designating that a column is a unique identifier for that row (say, a 64 bit integer). Thus, you can have something very much akin to pointers, albeit with different traversal mechanisms.

I think the point of the previous informed, experienced posters was: learn more about what is possible before passing judgement and declaring RDBs ''horrid''. Keep an open mind. There is a reason that RDBs have kicked OODBs behinds for the past decade.

Post any questions you might have on how to do what you are trying to do, and we''ll try to help.

Share this post


Link to post
Share on other sites
Hey OldGuy, were you calling ME knowledgable?????
if so then, WOOOOHOOOOOOO I''m 32 and finally knowledgable about something........ :D

If you weren''t talking about me then just ignore the previous comment.....

Share this post


Link to post
Share on other sites
quote:
Original post by EvilCrap
the problem is that keys are specific to elements, therefore they can get vastly duplicated in relations like one-to-many, where one table will contain many elements with duplicate keys relating to a primary key table. this is horrid.

wouldnt it be faster and more memory effecient to have keys that can point to tables? thisaway, i can have a customer table where each customer has a specific order table, instead of customers relating to a single order table. - the jumps between data would be decreased a ton. (if linked lists are used, and even more if complete redim is used). querying orders without going through customers could be dont by a collection table, maintaining all order tables.

The problem is that you''re now splitting one table into a load of smaller tables on the basis of one property. Most of the time, you don''t want to do this as there are many other queries you might want to perform on the data which will be complicated by splitting it arbitrarily like that. And even when you do want it split up, some operations are still much faster when performed on the table as a whole. (It might be quicker to sort a single order table than to sort a lot of smaller order tables with the same total amount of orders, for example.)

Don''t forget that most relational databases are heavily indexed, which largely makes up for the lack of pointers.

There are some other reasons, to do with referential integrity, and implementing relational algebra, but I think the above point is enough.

[ MSVC Fixes | STL | SDL | Game AI | Sockets | C++ Faq Lite | Boost ]

Share this post


Link to post
Share on other sites
Today''s relational databases are actually a thing of marvel. A large, well-tuned RDB can allow thousands of queries over millions of records with blazing speed. Today''s RDB query optimizers are amazing pieces of engineering. It may seem paradoxical, but some of today''s best software engineering work is in the RDB area.

Share this post


Link to post
Share on other sites
not to create a flame magnent, but,

one thing ive noticed is that many db gurus/students have little to no programming expereince (one of my professors has some COBOL under his belt...)

i understand that dbs are created by programmers, but - are they designed/oriented for none programmers?- judging sql, i think so. if so, then maybe there are many deficiencies that could be improved apon (again, i am happy for feedback regarding like pl-sql), without needing to change the entire concept, to say, oo.

Share this post


Link to post
Share on other sites
They''re a general-purpose tool, built around the mathematical basis of relational algebra. Yes, for any one given problem, you can certainly hand-code a faster and more compact solution, but for providing a general and efficient solution to all your data access needs, there really isn''t anything better than the relational model right now.

[ MSVC Fixes | STL | SDL | Game AI | Sockets | C++ Faq Lite | Boost ]

Share this post


Link to post
Share on other sites
There are really two aspects of programming when dealing with relational databases. One is the SQL actually used to interact with the data: selects, inserts, updates, etc. Another is the code that hooks up to the database interface. Usually written in C/C++, it might run against a general purpose interface such as ODBC, or a proprietary interface that is rdb-specific (e.g. OCI for Oracle, ctlib/dblib for MSSQL, etc). There are experts in SQL who know nothing about the actual interface; people who know the interfaces but not SQL; and those who know both. You probably want to learn SQL first, especially while in college, and leave the interface until you know which specific database you''ll want to be an expert in.

Share this post


Link to post
Share on other sites
quote:
Original post by EvilCrap
not to create a flame magnent, but,

one thing ive noticed is that many db gurus/students have little to no programming expereince (one of my professors has some COBOL under his belt...)

i understand that dbs are created by programmers, but - are they designed/oriented for none programmers?- judging sql, i think so. if so, then maybe there are many deficiencies that could be improved apon (again, i am happy for feedback regarding like pl-sql), without needing to change the entire concept, to say, oo.


Over the years I have known (and still know) a few DBA''s. Only one of them didn''t have a coding background. That said, SQL may, at the outset, look very simplistic but once you get beyond SELECT and UPDATE and into Triggers, Nested Queries, Nested Triggers, Recursive Relationships, etc, etc, you being to see the real power of SQL and RDB''s.

I guess the other thing about RDB''s and their Administrators is that they are there to manage a precious commodity ... Data. They have to tune, maintain, backup, restore etc, etc, the information that keeps a business competitive. It''s no good storing masses of information, if the system it is stored on takes hours to retrieve and/or spends most of it''s time offline.

That said over the last few years data warehouses have become more and more prominent. Data is being replicated and transformed from multiple sources into large, generally denormalized warehouses. These add OLAP, Cubes, Data Mining, Natural Language Queries and host of other things to the DBA and Developer toolbox. XML is also having a positive effect on the translation of object based data to structured tables and visa-versa, indeed both the current versions of Oracle and SQL Server allow direct XML updates and selects.

You never know, you may find yourself working with an RDB in the future ... MMORPG''s have to store data somewhere.

Share this post


Link to post
Share on other sites