2003 QUOTES

The weekly quotes contain errors that anybody with basic knowledge and understanding of data fundamentals in general, and the relational model in particular should be able to identify. The  purpose of the quotes is two-fold and educational (a) to demonstrate lack of foundation knowledge in the industry and alert practitioners to it (b) as a means to test oneself on grasp of data and relational fundamentals. The reader unable to recognize the errors is advised to pursue proper education, but exercise extreme care with respect to the quality of sources providing such (the site does provide some recommendations).

[A relational database is a] method of representing data using following general rules so that it is "easy" to process: 1. Store data in tables. 2. Each table has rows. 3. Each row in a table has the same fields (ie ID, Name, Age, SS#, Friend1_ID, Friend2_ID) 4. A row's field (ie Friend1_ID) could reference another row of same or different table. --James, Online Exchange,http://www.dbforums.com 12/12/03

I use relational databases in my work every day. Bricolage of course runs on PostgreSQL, and I've done some work on DBD::Pg. But after using various RDBMSs over the years (Access, MS SQL Server, DB2, MySQL, Oracle, PostgreSQL), I've come to one inevitable conclusion: RDBMSs are all just total crap. Don't get me wrong, I think that they have their place. I just don't know what that place is. But no decently designed object system that I've worked on (let alone a poorly designed system) has found an elegant way to interact with databases. Sure, DBI makes things easy for Perlers in that it provides a pretty standard, uniform interface for accessing databases of all kinds. But if you're designing even a moderately sophisticated application, you still run up against the complete incompatibility of object-oriented design and relational storage. They're just completely orthogonal to one another. --Online Exchange, http://use.perl.org/~Theory/journal 12/05/03

I did see your plea for help with funding Chris Date. Frankly, I think his approach is "dated", from what I could understand from talking to him at VLDB'99 in Edinburgh. We now live in a world of Agents, Semantic Web and XML. That is our main research focus here. Thus we would not be interested. --Faculty member, Academic institution, Scotland 11/28/03

Alterian accepts data from a variety of sources; the most common being fixed record length files, comma separated ASCII files (*.csv), or those accessed through an ODBC driver. Source data from a number of tables will be loaded in a relational design with the links between tables established either during or after the load process. Thus, the time database administrators spend normalizing, denormalizing, and aggregating the data is minimized. --On Performance,www.alterian.com 11/21/03

Rules can access objects that have been asserted into working memory. With relations, rules can access objects that are related to objects that have been asserted into working memory, but have not themselves been asserted. That is, relations allow a programmer to navigate an application's object model in rules, using object references that are either data members or method invocations. Prior to this feature, all related objects had to be asserted to working memory and objects had to be related through bound variables in rule conditions. --ILOG JRules Technical White Paper, www.ilog.com 11/14/03

MySQL is not a toy database - it is far superior to many I have used in my long career. The lack of constraints is not a weakness. It is eminently possible to create reliable applications without the need for database constraints - I should know because I have designed and built many applications that did not use database constraints (mainly because they were not available). Developers only rely on database constraints to circumvent their sloppy code. Anything that can be done within the database can also be done within application code. I have seen what happens when poor programmers try to shift logic from their code into the database - they get it wrong and then blame the database for their incompetence. I am used to designing and building applications without relying on database'features', so I write my code accordingly. It also means that the logic is maintained in one place and not it bits and pieces here and there. --Tony Marston, http//groups.google.com, comp.lang.php 11/07/03

Storage Independence When you use relational design, you client programs need to know where your data is stored, and in what format, what table, and what the relationships are between those tables. XML Schema allows you to write applications without that knowledge, and allow the DBA to map structured data to physical table and column storage. --Oracle XML DB FAQ, http//otn.oracle.com 10/17/03

Records in a relational database can be manipulated by using Extensible Markup Language (XML) ... Typically, you work towards achieving the third normal form, because it is a compromise between too little normalization and too much … Denormalization is the process of reversing normalization to generate tables with more fields that require fewer joins ... Related items of data can be retrieved efficiently by using Structured Query Language (SQL), regardless of whether the items are stored in one table or many tables. --Microsoft, Analyzing requirements & defining .NET solution architectures - exam 70-300 10/10/03

As I've said before, 1. the only normative definitions of XML, and of Namespaces, operate almost completely at a syntactic level. 2. I've been in software for 20 years and I've seen lots of interoperable cross-platform syntax and very rarely an interoperable cross-platform data structure or API. Obviously, once you're dealing with some XML inside of a program, you think in terms of the structure. But XML's interoperability is strongly linked to the fact that its definition is syntactic. --Tim Bray (co-inventor of XML) 10/03/03

Right off the bat they could see the underlying problem with current canned products: They all relied on relational database management systems (RDMS), and plain RDBMSs weren't built for this kind of business situation. Relational data models are inherently inflexible. To store information using the relational paradigm, you need to build the entity/relationship model first. Such a model is fixed, and if you need to add new information, you must design and code a new model. --Lee Thé, Use XML Where RDBMSs Fear to Tread, .NET Magazine 09/26/03

One thing that MySQL will not be including is XML support. In an interview with InfoWorld, Marten Mickos, the company's CEO, is reported as saying that "if XML in the database becomes mainstream, we will do it. My personal view is that the relational model is about as complicated as it can get before it gets too complicated". I agree. In fact I would go further I think the relational model has been extended beyond its natural limits. The corollary to this is that from a technical perspective it makes much more sense to use, say, Software AG's Tamino as an XML database that sits side by side with your relational database, than it does to try and cram this quart into a relational pint pot." --Richard Huxton, Archonet Ltd. 09/19/03

Reconstructing an order object with its line items from row-and-column tables requires two SQL queries and much coding. The same operation in an object database would require only one call. --Matisse Software Inc., The Best of Both Worlds 09/12/03

Let us make the understanding of normalization very simple. Forget about it! Normalization is for academics and in its strictest form is generally impractical due to its adverse effect on performance in a commercial environment, especially 3NF, 4NF and 5NF. --Gavin Powell, A Layman’s Approach to Relational Database Normalization, DataWarehouse.com 08/29/03

"Codd's aim was to free programmers from having to know the physical structure of data. Our aim is to free them in addition from having to know its logical structure." --Lazy Software 08/22/03

"Relational databases started to get to be a big deal in the 1970's, andthey're still a big deal today, which is a little peculiar, because they're a 1960's technology." --Mark-Jason Dominus, Short guide to DBI 08/15/03

"I have the task of auditing a system which is a VB front end and a SQL Server 2k backend. There is no project documentation. The database contains 171 user tables, 13 user views and 420 user stored procedures. It appears to be normalised to 3rd normal form. It is approximately 8.5 Gb in size. There was no diagram attached to the database but there were relations described between the tables. What are lacking are any Constraints or Triggers on any of the tables.The database is NOT replicated. Would anyone care to comment on whether this is normal/accepted practice? As someone who designs databases for a living, I would regard data integrity as moderately desirable, and I am also mindful that queries' execution plans are often optimized based on constraints. Based on the very sketchy outline above, why might someone have decided to forego Constraints/Triggers (there is no attempt to enforce integrity in the code)." --http//groups.google.com 08/08/03

"The star schema is a true third-normal form (3NF) data structure, through the points of the star are sometimes denormalized if the customer or product dimensions extend to millions of rows." --Lou Agosta, Avoiding Data Warehousing Religious Wars, DM Review 08/01/03

"Relational database management system: A relational database management system (RDBMS) is a program that lets you create, update, and administer a relational database. An RDBMS takes Structured Query Language (SQL) statements entered by a user or contained in an application program and creates, updates, or provides access to the database. Some of the best-known RDBMS's include Oracle's database product line, Computer Associates' CA-OpenIngres, and IBM's DB2.   The majority of new corporate, small business, and personal databases are being created for use with an RDBMS. Meanwhile, the idea of object-orientation has begun to contend with the RDBMS as the database management system of the future, sometimes in hybrid implementations."   --searchdatabase.techtarget.com 07/04/03

"D3 significantly improves on the relational data structure by providing the ability to store all of the information that would require three separate tables in a relational database, in a single 3-dimensional file. Through the use of variable field and variable record lengths, the D3 database system uses what is called a "post-relational" or "three-dimensional" data model." --Raining Data, The Innovative 3-Dimensional Data Model 06/27/03

"There are things that relational databases do very badly... A sense of things as parts of a whole-that's the desire for object databases, but there's an enormous investment in the schema for relational databases... Why does SAP [AG] exist?They've built data models of the world that more or less capture what an enterprise does. That's why you pay them a billion dollars, because when you sit around and try to create data models, you realize that's really hard...  developing and exploiting new data models is arguably the most vital challenge for enterprise IT."   --John Gage, Chief Researcher and Science Office Director, Sun Microsystems 06/20/03

"Can we arrange tables in a hierarchy form, just like we have folders and under folders we have files. so this way we sort of divide workspace? Say for company_A I create folder A and in it we can place files for that company. and similarly we can create a folder for company_B. Hence we can separate workspaces for better organization and management etc. So how can we accomplish as above, when we work with database? Is there a way we can arrange tables (of the database) in a hierarchy similar to folders and files? Say, I have one installation of Oracle on a particular computer. So how does one create separate table spaces, say for two different companies or projects ? (say, company_A and company_B are unrelated to each other)."   --Message on Oracle list 05/23/03

·  With regard to data modeling, you can't define attributes, which are of complex types (arrays, records, tables). Each relation has to be in first normal form. Or in other words: A "simple" natural structure must be divided into many flat structures (= tables/relations). The result is a complex structure of relations. ·  Result of a query is a flat table. Any complex structure, which has been input of the query got lost. ·  No way to define recursive programme structure (using SQL). ·  The type system of SQL doesn't match with the type system of the embedding language ("type mismatch"). ·  Controlling integrity constraints costs a lot of time (need to control the usage of primary/foreign keys). ·  Lack of mechanisms to control the physical level of the database (only simple clustering). ·  Definition of operations detached from data definition." --Fachbereich Informatik, Weaknesses of the Relational Model 05/01/03

"But the simpler model of the RDB world does not simplify applications, but rather makes them harder. A simple model is good for proving theorems, formal studies, etc. But in the real world, your real-world problem (application) determines the complexity. If your problem is simple, then RDBs work fine (simple, here, means simple, flat, tabular data structures, fixed length fields, no  relationships, no traversal, no nested structures, no user-defined structures, no methods, etc.).   --http//www.ootips.org   04/18/03

"The bad news is that you do have to design a database schema. I am not aware of a tool that can generate a database schema from, say, an XDR schema. Storing data in a database severely impairs your ability to alter your XML schema during the project lifecycle, especially after you ship. But the good news is that XML provides a buffer between your database schema and your code, so both can (at least theoretically) change independently." --www.xmleverywhere.com, XML Persistence 04/11/03

"Can anyone tell me where I can find guides on making a good table? Usually I go to Access Help." --dbForums, microsoft.public.access.tablesdbdesign 04/04/03

"These books credit the DBTG-CODASYL, proponent of the network data model in 1971, with the introduction of fundamental concepts such as physical and logical independence." --Massimo Dentico,  http://lists.tunes.org 03/28/03

"Summary: Pure OODB and RDB are fundamentally based on the same mathematical concept of relations. In RDB, it is relation/values. In OODB, the equivalent is class/instances." --www.dbforums.com 03/21/03

"I doubt that multi-value [databases] requires replacement of predicate logic or set theory, just the obsolete physical constraints of attempting to force multi-dimensional real data into artifical columns-and-rows, thereby embedding in the physical layer the architecture of the logical (and as you implied, giving rise to the normalization/de-normalization debate in the first place, when should be purely a physical implementation issue). Codd didn't reject the multi-value repeating group model; I contend that he simply had no perception of how to implement it ... I am certainly advocating a [data model] replacement, but for the two-dimensional physical data base architecture used in the fashionable, so-called relational databases."   --S. VanArsdale, e-mail communication 03/14/03

"The mother of normalization was not someone idly thinking about data integrity issues, but people concerned with getting RDBMS to perform adequately. Only afterwards did people start "covering up" the fact that the reason normalization rules were invented was to address performance, and make believe that the normalization rules were invented to deal with data integrity." --B.P. Margolin, microsoft.public.sqlserver.programming 03/07/03

"I am interested to become a Database Designer, pls guide me as how I can achieve this. Also suggest some books for the same. Also pls tell me what parameters are to be considered for sizing informations so that the database requirements can be known."   --Submitted by reader 02/28/03

Chamberlin: Well, there are a lot of hyperlinks in the world, aren't there? I have a talk, "A Brief History of Data," that I often give at universities. And in this talk, I refer to the Web as "Bachman's Revenge."   Haderle: I know that the IMS guys are saying, "I told you so."   --David Stodder, Bound to Succeed, Interview with IBM's Experts, DB2 Magazine 02/21/03

"This is an object database - where information is stored in a way mirroring how it occurs in real life, not broken up into columns and rows then joined (relationally) back together as tables." --Eric Wilson, Object Databases Find a New Lease 02/14/03

"We are loading our tables daily without truncating them. We do not want to end up accumulating duplicate rows and therefore decided to rely on IGNORE_DUP_KEY clause to silently reject dupes. But if a row is in fact different we'll preserve it because our original plan was to build a unique index on all the columns. But the following quote from the Transact SQL Manual looks like a show stopper to us   "You can specify up to 31 columns in a single composite index in Adaptive Server 11.9.2 and later. All the columns in a composite index must be in the same table. The maximum allowable size of the combined index values is 600 bytes. That is, the sum of the lengths of the columns that make up the composite index cannot exceed 600."   Vast majority of our entities will have more than 31 attribute. Where are these limits coming from? Is there a way to bypass them (other than breaking a table into multiple pieces)? Is Sybase using some sort of hashing behind the scene to implement this feature?"   --forums.sybase.com: sybase.public.ase.general 02/07/03