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.....
data bases
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.....
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.....
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 ]
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.
Author
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.
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.
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 ]
[ MSVC Fixes | STL | SDL | Game AI | Sockets | C++ Faq Lite | Boost ]
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.
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.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
