data bases
Author
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.
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.
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.
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
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
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
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
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...
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...
Author
-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?
-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?
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
Author
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.
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.
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.
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.
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.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
