2006 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).

Dawn Wolthuis: Is there database theory that includes identification of 1. the fact that values for an attribute either were or could have been derived? 2. how values for an attribute were derived? 3. how values for an attribute could have been derived? Kenneth Downs: In order to even begin to deal with this question, you have to deal with the 800lb gorilla called "Normalization", which forbids derived data. It states basically that derived data is part of life, and since normalization can't deal with it, normalization is not enough to guide serious application development. But you also can't throw it away, because it gives good things. --comp.database.theory 05/19/2006

...as a guy who is now designing his own db system, I figure I'd use the most precise terminolgy possible. The truly die hard relational weenies will deny that SQL databases are relational, because they doesn't meet some criteria set by Codd a zillion years ago, as though Codd's notions of relational are the only one allowed. I do this so the pedants don't say "How can he design a DBMS, He doesn't even know the difference between SQL and relational? BLATHER BLATHER BLATHER BLATHER". You know how some people are: http://www.dbdebunk.com/index.html. These guys apparently base their careers on "debunking" SQL databases. --Damien, damienkatz.net 5/5/2006

The incomplete premises of the RM cover the data but not the process, with the result that other theories need to be harnessed in order to manage the processing of data. For example, the RM does not have an atomic element, or definition of anything related to a formalised line of SQL code that we might call a program, yet such code has been stored in RDBMS (as stored procedures) for almost a decade ... The RM is a theory of data objects. It fails to address program objects. (eg: sql stored procedures). And as far as the assertion that a theory of data objects is different from a theory of data processing objects, I'd be inclided to think that Date has never seen it this way because all he is interested in is the data objects. OTOH it is my contention that what will be required in the longer term will be not just be a theory of data objects, and another theory of program objects, but an integrated theory of both data and program objects, together known as data processing objects. --Pete Brown aka mountain man, comp.databases.theory/ 4/27/2006

Rycamor: I'm willing to bet that by the time you implemented the equivalent of constraints, triggers, etc... in a system like this [Revayler], you would be running no faster than a typical SQL DBMS. William Tanksley: Chalk up one more person who's missed the point. This isn't a relational database. Those techs you mention are used to make a denormalised SQL database act like a normalised SQL database; they aren't needed if your relational database is normalised or you're not using a relational database at all. --Object Prevaylence: Get Rid of your database?, developers.slashdot.org 4/21/2006

Besonen: i didn't know relational database luminaries had such rancor towards most relational database designs. any db folks familiar with the criticisms these folks have and the real-world consequences (pros and cons) of failing to adhere to a "true" relational design? Koz: Date doesn't talk about the practical consequences, frankly the whole book is academically interesting, but I'm sticking with my object oriented design. deirdre: Any of Joe Selko's [sic] SQL for Smarties stuff (including any of his several books) is worth reading. Oh, you mean like only using 15 tables when a "true" relational design would have 35 tables and each query/insert has 10 more joins? Sure. Usually, there's a point where being more "relational" doesn't make business sense in the terms of how much hardware / developer time you need to throw at it to be pure "relational." billsaysthis: Fabian Pascal is a really smart guy, and I wish he would have had better luck, but he just can't get over the fact that the database industry decided to follow a different path from his golden way and as a result he's spent the last 20 years in a Sissyphian battle. I remember writing an article for Software Development close to 10 years ago which he took umbrage with. Heck, CJ Date can be a hardcase too, he wrote a letter to the editor about another of my articles but I took that as a badge of honor because he's such a gentleman. --forum.textdrive.com 4/14/2006

Yes, XML is a way to structure data into documents. XML must be hierarchichal, otherwise the data wouldn't be structured. --asterix, sitepoint.com/forums "Unknown" and "not applicable" are more like different senses of the same thing, not two opposite things. Using NULLs is not very _difficult_ anyway, just a bit tedious because it is another case to handle. Please note that I did not say that you MUST use NULLs, just that they were perfectly valid to use in a design. --Rhino, mailing.database.myodbc 4/7/2006

Gene Wirchenko: XML is an alleged solution looking for a problem. Tom Bradford: This is a '1997' argument whose validity is no longer acceptibly spoken as such a generalization. The W3C has been more than happy to synthesize the problems for us through the introduction of XML dependencies ... RDF, SVG, XHTML, et al. The problems are here, welcome or not. Beyond that, there have definitely been problems to which XML is an ideal solution. Mixed content is a major one. Parts explosion is another. There have been many who have argued that the relational model is all-encompassing, and that is definitely true. But just because you 'can' do something with a particular solution, it doesn't necessarily mean that you 'should' do something with a particular solution, or even that the solution is ideal in all cases. --comp.databases.theory 3/31/2006

In the middle of this, there is a unforeseen trend in the use of the file system as a storage medium. Yes, the file system. Guess what? Forget the FAT, please. Current file systems are much more stable and efficient than older ones. Modern filesystems are hierarchical, and can store arbitrary objects. Support for journaling, and better metadata management means that the filesystem is now a better choice for many situations. Several web publishing engines (blogs, wikis, and even full-fledged content management systems) support filesystem-based storage for text notes and documents, which were previously stored (in a hackish and haphazardous way) into DB blobs. The full filename is now a primary key, and flexible relationships between entities can be expressed as hiperlinks. --Carlos Ribeiro, Alternative Database Systems, pythonnotes.blogspot.com 3/24/2006

There have been, there are, and there always will be NULLS in the real world ... Information is an abstraction which may or may not exist. If it exists I call it data or information. But if it does not exist (within the DBMS) for any given reason, then it is called "missing", void, or null ... The model cannot be complicated by essences of reality. In reality, information may be partial, and thus have elements in it which have null values ... Modelling holes in information is straightforward with the use of nulls. You either have them, or you dont. You could probably replace then with a value, say x, but what would this gain? ... So what? The original design schema is simply missing information for these elements, and this information needs to be entered, and/or determined and entered. Why should a qualified database professional spend time on such a problem when the only real and viable solution to this problem is to identify the missing information and then to get it into the database? Normalisation appears to be a theoretical sledge hammer trying to cover up underlying integrity issues without actually solving the integrity issue at its fundamental level. At least this is the impression I get after reading the above reference. It's the long way around a problem, and does not in fact ultimately solve the problem of the missing information, which the original schema--by the guidance of the RM presumeably at implementation - should have been required as mandatory. --Pete Brownm, comp.database.theory 3/17/06

Alex Savinov: I am sorry, but the only thing I can advice is to read something about concept-oriented model. It is difficult because the description is bad (I actually lost an interest to it because almost everything is clear for me. Tony Andrews: So let's get this straight. You have single-handedly developed something called the "concept-oriented model", which you claim is better than the relational model. However, you have not managed to explain this model in a way that anyone other than yourself can understand, and have now lost interest in trying to do so. Is there any point in even bringing it up in discussions any more? --comp.database.theory 3/10/2006

... a tagged, text-based system can be understood on a human level. If you open a relational DBMS file in a text editor...well, don't do it. XML makes the innards understandable on some level. Now, obviously some of the structures are too complex to fathom, just as some novels are too complex to fathom. --George Burt, group/dbase.internet 3/3/2006

I presume you are talking about enforced referential integrity? Why does it have to be enforced? You can have relations [between tables] without them being enforced. Many of the larger database applications, such as SAP R/3 and Peoplesoft don't use enforced foreign key constraints because of speed issues. Does that mean that Oracle or SQL Server aren't relational when used by these applications? The ability to have relationships (as you said prior) is what makes a relational database, according to most popular views. You can have relationships without them being enforced. MySQL has always supported that. If we want to get technical about it, any SQL database is *not* a relational database. Just check out the rants of Fabian Pascal as http://www.dbdebunk.com or check out comp.databases.theory as well. One last note, just to satisfy your requirements, MySQL supports foreign key constraints for the transactional table type, InnoDB. Does that make it relational now according to your definition? --LoneGumMan, episteme.arstechnica.com/groupee/forums/ 2/24/2006

Mapping is a big problem for many complex applications. So what happens if we put all the tables into one table called ENTITY? I have more than 300 attributeTypes.And there will be lots of null values in the records of that single table as every entityType uses the same table. Other than wasting space if I put a clustered index on my entityType coloumn in that table.What kind of performance penalties to I get? Definition of the table ENTITY --------------- EntityID > uniqueidentifier EntityType > Tells the entityTypeName ... Name > LastName > CompanyName > 300 attributeTypes OppurtunityPeriod > PS:There is also another table called RELATION that points the relations between entities. --erdsah88, forums.oracle.com 2/17/2006

First normal form (1NF). This is the "basic" level of normalization and generally corresponds to the definition of any database, namely: It contains two-dimensional tables with rows and columns. Each column corresponds to a sub-object or an attribute of the object represented by the entire table. Each row represents a unique instance of that sub-object or attribute and must be different in some way from any other row (that is, no duplicate rows are possible). All entries in any column must be of the same kind. For example, in the column labeled "Customer," only customer names or numbers are permitted. Second normal form (2NF). At this level of normalization, each column in a table that is not a determiner of the contents of another column must itself be a function of the other columns in the table. For example, in a table with three columns containing customer ID, product sold, and price of the product when sold, the price would be a function of the customer ID (entitled to a discount) and the specific product. Third normal form (3NF). At the second normal form, modifications are still possible because a change to one row in a table may affect data that refers to this information from another table. For example, using the customer table just cited, removing a row describing a customer purchase (because of a return perhaps) will also remove the fact that the product has a certain price. In the third normal form, these tables would be divided into two tables so that product pricing would be tracked separately. Domain/key normal form (DKNF). A key uniquely identifies each row in a table. A domain is the set of permissible values for an attribute. By enforcing key and domain restrictions, the database is assured of being freed from modification anomalies. DKNF is the normalization level that most designers aim to achieve. --mynock, dvdforum.nu/forum/ 2/10/2006

Being one of the dumb rubes that learned sql from books and "on the job" training, I'm not as grounded in database theory and academics as I'd like to be. So any of you that feel you are more well versed in database theory or have your PHD's can you take a look at this site: http://www.dbdebunk.com/ Is this guy for real? Does he really understand what he's saying or just making money from hype and conflict? I don't understand everything he says but the gist seems to be: 1.. Most developers don't understand database fundamentals because they don't go to school or they take tech classes supported by a specific product vendor (oracle, sql server, etc.) 2.. SQL is a crappy, not completely relational data language. 3.. Most RDMBS such as oracle, sql server, mysql are also not "fully relational" and lack truly relational features (whatever those are. ) 4.. Only a truly relational database (again I don't understand his definition fully) can or should ever handle business data. Other database systems such as object-oriented databases, hierarchial, xml based or multi-valued, in a word: suck. 5.. Joe Celco and his like are morons. 6.. One should never, ever, ever, under any circumstances DENORMALIZE. Any performance benefits are due to crappy physical implementation of a vendor's attempt at an RDMBS and cause database corruption to boot. Again, I'm sure many of you have heard of these guys and I'm not trying to give them undue publicity. Much of what they say has merit, from what little my po' uneducated self can understand. But some of it seems so extreme and so "out there" i just wanted to see what this little houseoffusion community had to say on the matter. --Craig Fregas, houseoffusion.com 2/3/2006

Notice one of the great benefits of the objects-first persistence approach: no ugly SQL, no worries about whether we need to do an INSERT or an UPDATE, and so on. All we see are objects, and we like it that way. ... In essence, a relational model deals with collections of relations, which we commonly refer to as tables; each relation is a row, each item in the tuple is a column, and an entire language built around the idea of manipulating data in this relational format provides access. ... From an entirely different angle, there may be other, far more practical reasons to abandon an objects-first approach. Perhaps noobject-relational mapping product on the planet can deal with the relational database schema you inherited as part of your project, or you're simply more comfortable working with the relational model and SQL than an object model (although that would likely imply you started life as a database administrator and later became a Java programmer). --Ted Neward, EFFECTIVE ENTERPRISE JAVA (Submitted by Mårten Dolk) 1/27/2006

Relational Database: A collection of "related" databases, for example and travel agent booking system consisting of customer, airline and account details, can be combined and would be referred to as a Relational Database. --Steve Turvey, Road test: Four Databases Tested, builderau.com (Submitted by Rob Porter) 1/13/2006

It seems a logical argument to me. The database can have all the integrity it wants but applications can still load junk into it and/or misrepresent it’s contents. --Tom in Dublin, jooto.com/blog/ 1/6/2006