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

I have done an Entity-Attribute-Value database design before. The big advantage is that much of your logical model is stored as data rather than as schema, so changes to the logical model can be made without changing the schema. And if you write your sprocs correctly, you won't need to change them either. The drawback? VERY complicated SQL code. The main reason I used this was for a client that did not have a clear understanding of their own requirements, but needed a working application on a deadline. The EAV schema allowed me to deal with constantly redefined business rules and requirements. Phase two of the project would flatten out the schema, assuming most of the discovery was accomplished in phase 1. I would not shirk from using EAV again, but project managers balk at it because the cannot understand the concept or the read the SQL code to support it. This always ticks me off, because it's like a project manager telling a developer to code in BASIC using GOTO statements because that is all he can understand --blindman, sqlteam.com/forums/ 12/17/2005

No, XML is concerned with representation (i.e. syntax). No, XML is semantic. Syntax defines that '<' and >' and ' --Decaff, slashdot org 12/10/2005

IMO database are supposed to be dumb storage, they are intended to manage the storing of data, not business logic ... Let database be dumb, and application smart, after all the application is a model of the business process, the database is just storage to support and expedite the data being pulled into business objects. --cam, Making Database Stupid, hulver.com 12/3/2005

And frankly theological debates do the same thing, if done by persons who really care about what they believe. The interpretation of religious beliefs and foundations bring about real change in people's lives. Hence, by understanding theological predicates we can make it practical too. The thing that is funny is that understanding exactly the difference between mathematical relations and relational database relations is interesting and makes some people think, but on the whole, it is not going to change the average programmers thoughts or abilities to build a proper database system. It reminded me of some very interesting discussions I have had surrounding creation theology, most interestingly dinosaurs. Say dinosaurs lived at the same time as Adam and Eve, or three million Earth years ago, will it make any difference when the poor person asks me for a meal today at lunch, or when I get cut off in traffic? Not a bit. But it does make you think and is great stuff to know! --Louis Davidson, microsoft.public.sqlserver.programming 11/18/2005

The Myth Of Data Integrity --http://jooto.com/blog/?p=22 11/11/2005

...data is best kept closest to its natural source rather than at the intersection of a row and tuple of a database... Gartner to DBAs, BI vendors: Time to reinvent yourselves, ZDNet.com 11/4/2005

Bill "de hOra"(?): "...tired of writing ER specifications, tired of building database schemas, ... no longer need to thanks to RDF" (quoted by Danny Ayers). Danny Ayers: I understand XML, and I understand schemas, XSD or RelaxNG. Schemas define the syntax of an XML document ... Much of relational database theory *is* RDF theory... Leigh Dodds: Danny touches on the RDBMS changes in his comment. Basically you need to adapt the table structure every time you want more data. Either that, or you end up with generic “extension” tables like: id, name, value. Basically a big Map of additional properties. This gives you a bit extensibility, at the cost of limited flexibility with SQL. Think about when you have lots of useful data in that kind of setup, and have to write hairy self-joins to do something useful with it. What Danny didn’t touch on is that obviously not only do you need to change the RDBMS table structure, but you write new loading routines to populate that data. So there’s extra code to write (or at least change) also. With RDF you can just pour data into your triple store, and then work with it immediately. This is much more agile. --dannyayers.com 10/28/2005

If we step back and look at what RDBMS is, we’ll no doubt be able to conclude that, as its name suggests (i.e. Relational Database Management System), it is a system that specializes in managing the data in a relational fashion. Nothing more. Folks, it’s important to keep in mind that it manages the data, not the MEANING of the data! And if you really need a parallel, RDBMS is much more akin to a word processor than to an operating system ... Why should we tolerate RDBMS opinions on our data? We’re the masters, RDBMS is the servant, it should shut up and serve. End of discussion. --Alex Bunardzic, Should Database Manage The Meaning?, lesscode.org (Submitted by Dave Tallman) 10/21/2005

SQL is inadaquate to the task of fully utilizing the RELATIONAL MODEL because it doesn't have any way to EXPRESS RELATIONSHIPS other than "table". Isn't this a limitation of the relational data model itself? I think only the entity-relationship model can distinguish between relationships and other data. Once you convert your model to the relational data model, you've lost that distinction. This is not an SQL-specific problem. At least this is what we learned at our university on a database course. --adam6, slashdot org 10/14/2005

And with relational databases you just make something up that has nothing to do with the application? Come on, that's a bogus argument. It's not like you can't get your data out of the OODB ever again. There are dump tools, query shells, etc. Besides, in 15 years, when the current application goes out of production, who knows wether we're still using RDBMS? More of a problem is the concurrent use of a OODB schema by multiple applications, but I can imagine ways of working around that (i.e. have a common base layer/library). --Edward James, joelonsoftware.com (Submitted via a link by David Eldridge by Anthony Wilson) 10/8/2005

What I need in a database is place where I can persist and retrieve data. Those are my requirements — let me persist data somewhere, then let me get it back when I need it, in the form that I need it. Relational databases — whoops, I mean SQL databases — have allowed me to do this for years. And how exactly can that be so bad? --Deane, gadgetopia.com 9/30/2005

Kevan: We are planning an application where users will be defining 'objects' (eg a customer)and then adding 'fields' to those objects (eg firstname, lastname etc), then subsequently creating records of data for those objects. We don't know in advance what the object or fields names will be, although the field types available will be generic pre-defined types (integer, short text, long text etc) I am unsure of the best way to implement this in the database and maintain a reasonable efficiency (could be a few hundred thousand records for some objects, but not millions). The goal is to hide the database from the user and present a simpler system of data that is associated with other data. Ideally, from a users perspective they would not be aware of the data storage strategy (database or otherwise). The system will primarily capture data from web forms and then provide search facilities to retrieve this data. This will not be a query building, reporting or charting system. I have a couple of throughts at this stage: 1) Create a fixed schema to store the data with one table to store ints, another table to store short text, another for floats etc. Data retrieval would be via joining the tables and using aliases on each, but I suspect that there would be a limit to the number of joins/aliases (or some other limit) permitted by the database that would make this infeasible. 2) Create a table with, say 10 integer columns (named int1, int2 ...) 10 float columns (named float1, float2, float3 ...) 10 varchar(100) columns (etc) 10 datetime columns etc Then only using the columns relevant to the data required by the user - some metadata would be used to describe which columns are in use - the rest of the values being null. We could perhaps have multiple identical tables such as these to handle records which need more fields than are available in a single table. Any thoughts appreciated. bdimple, senior DBA: You will find a couple of Data Models on this page entitled 'User-Extendable ...' that might give you some ideas: www.databaseanswers.org/data_models/index.htm There is also an online 'Information Catalogue' facility on the same web site where you could build your own Database directly. You need to contact the guy who runs the web site to get details. --dbforums.com 9/23/2005

SQL is the language used by most databases and has been advocated as a means to access specific Web data ... SQL is said to be relationally complete in that it can be used to express any query supported by predicate (or relational) calculus. By tightly coupling Web data to SQL using SQL extensions, we get the benefit of being relationally complete (since SQL itself is relationally complete) and are left with simpler tasks of ensuring that our SQL extension is robust in that it is sufficient to capture all Web data, including hierarchical representations (XML) and relational representations (links). ...” --Wood, C., Ow, T. WEBVIEW: An SQL Extension for Joining Corporate Data to Data Derived from the Web. Communications of the ACM 9/16/2005

Beekeeper123: I am a novice user of Microsoft Access. I typically do not use Primary Keys. Everything I read indicates that the primary key is used mainly to speed up the search of a database. I am currently just using two small tables which contain a common record ID. I am doing querries on these tables and I have not discovered any errors. Based on what I have seen I still obtain the correct information from my querries. Is it critical that I use a primary key or is a nice to have with large databases? Jeff Bridgham, Purdue University Graduate School Data Analyst: Establishing a primary key is never necessary even in a large database. There are advantages to having a primary key mainly that Access will make sure that the field will contain only unique values. This will stop a user from accidentally entering a duplicate record. Access will also make sure that the primary key contains a value again this is necessary to keep each record uniquely identified. pbrodsky: You can always index fields for efficiency without creating a primary key. Without a primary key, however, the database engine cannot guarantee that each record has a unique identifier. A unique identifier is essential if you want to ensure that you are working with the correct record. Otherwise, you can have multiple identical or similar records and it can be difficult (or impossible) that you have located the correct one. --tek-tips.com 9/9/2005

The main problem of dbdebunk is that they do not propose anything new and their main argument is that we do not need anything new because we have already one good theory and that is enough -- the main problem (in their opinion) is that this theory is not used correctly and there exist bad boys who do not understand it (bad programmers, bad database developers and so on). Those bad boys produce bad products and try to enhance this ultimate theory and its is crime. Why that theory is good? Just because it is based on set theory (stupid argument, is not it). I would qualify dbdebunk as religious fanatics who identify themselves with this one theory and speak on bahalf of it. They think their role consists in protecting this theory and the way they chose consists in isolating it from the outside world, frozing in its current state and fighting with any type of heretics. So it is really dogmatic and orthodox site (unfortunately). And anybody who wants to learn something new, unusual, surprising and interesting should keep a distance from this site because they think that they know what truth is. --Alex Savinov, comp.databases.theory 9/2/2005

tblanchard: If XML is an "interchange" format - then why am I storing it? Mike Champion: What (authoritative) source gave you the impression that XML is only, or even primarily, an "interchange" format? It started life as "SGML for the Web", and SGML is not primarily an interchange format. Its usefulness as an interchange format is alluded to in the XML 1.0 spec, IIRC, but not stressed. Anyway, "interchange" formats have a way of needing to be stored efficiently and reliably, with transaction management, queries, reporting, etc. as the sheer volume of the data increases, the importance of the data for business increases, and the transactions become longer-running and more stateful. The logical way to handle data that must be handled efficiently, reliably, queried, and with transaction management is in a DBMS. Hence specialized XML DBMS's evolved, and RDBMS's have added XML support. --http://lists.xml.org/archives/xml-dev 8/26/2005

robc: My boss gave me an assignment to find out how SQL works - he is looking for a very technically detailed explanation.The explanation has to do with 'sets' and 'trees' etc. I have been searching the net and books, but they do not go into enough detail concerning this. I think that the explanation my boss wants, is so technical that it is beyond the scope of most books and sites concerning SQL. Can anyone point me in the right direction? MattR: What does he want to know? Why? The explanation has to do with 'sets' and 'trees' etc. robc: He wants the technical reason why it is faster than flat files, not the conceptional [sic] reasons. I thought the answer to his question was obvious, considering usage of tables, indexes, etc., but he is looking for another type of answer. He wants me to have a complete, technical understanding, but he wants me to find the answer. --http://forums.devshed.com 8/19/2005

MySQL is a relational database system. It has to be in order to use SQL (Systems Query Language) --bgcbgc, zdnet.com Don't use primary keys that have meaning for the end user, such as invoice number or the ISBN value. -- Giuseppe DiMauro & Francesco Balena, PRACTICAL GUIDELINES AND BEST PRACTICES FOR MICROSOFT VISUAL BASIC AND VISUAL C# DEVELOPERS 8/12/2005

In spite of what Fabian Pascal says, applied math spends a lot of time on "things we don't know" ... --Joe Celko, dbforums.com 7/29/2005

I think that's a widely inaccurate notion, that if data models don't follow a mathematical concept, they are not "correct". Data model follow rules, If the model conforms to the rules, it is correct. --Ian, comp.databases.theory 7/22/2005

did i mention i like nulls? heck, i even go so far as to say that all columns in a table except the primary key could/should be nullable. this has certain advantages, for example, if you need to insert a child record and you don't have a parent row for it, just do an insert into the parent table with the primary key value (everything else null), and voila, relational integrity is preserved. but this is, admittedly, a bit controversial among modellers. --r937, dbforums.com 7/15/2005

"relational" is the key feature of relational databases: they are interesting not because of a given element (i.e. row in a table) on its own, but because of the relations between rows and tables. If you don't need relations, then there's no reason to use a relational DB. The whole point is to use multiple tables ;) Otherwise you just have a flat file. --Introduction to databases, fredshack.com 7/8/2005

Relational systems are useful for a wide variety of tasks specifically because they are limited in their expressive power. This limitation in their expressive power means that certain desirable properties are maintained. The objects that are recognized in the relational programming model are scalars, tuples and tables. Most operations are closed on the set of all tables -- that is to say the take tables and produce tables. This means that you can compose operations in various kinds of ways and still have more raw material for further operations. To take a more modern view of this: relational databases are about the reuse of facts. The process of designing a database is one of analyzing factual relationships so that eventually each fact is stored in one and only one place. This, along with the closed nature of relational operations, facilitates recombining these facts in various novel ways. I believe this is the source of the relational model's sustained popularity. The cost is that the resultant [sic] model is not ideal for any single application. I believe this is the nature of the "impedence mismatch" -- you are dealing with an off-the-rack, one-size-fits-most-applications representation of data. Naturally, for complex applications with severe performance constraints, a more tailored representation is required. I've never had the cash to hack around with OO databases, so I'd like to learn more. Do they support the kind of composition of operations that you get with relational systems? Presumably objects can be re-used in different applications, but how well does this work in practice? --hey!, slashdot.org 7/1/2005

This is my area of experience. Relational Databases seem to make their living off querying semi-static tables of flat data. I write applications that deal with a constrant [sic] stream of data (of varying complexities). I have tried storing to an RDBMS and the performance is abysmal. I currently use Objectivity/DB and am very pleased with the performance. I *could not* use a relational product to pass data between my components they way I do with Objectivity and achieve anywhere near the same performance. --Jim Melton, comp.databases.object 6/24/2005

But there is one fundamental value without which a model and a database cannot exist at all - it is NULL - and it has its semantics defined at the model and at the system level as absence ... Nulls are equivalent of empty set (absence, hole etc.) and I can imagine a model without any other elements but not without nulls. In other words, null is what any model starts from and after that we can add any other non-primitive elements we want to see :-) Those other elements may pollute the model or may be argued to be unnecessary, but not null values. Since nulls play such a role they are actually not true "values"( in the sense we use "normal" values, say, 5, 10 or "some text"). --Alex Savinov, conceptoriented.com 6/17/2005

relational databases are basically 2-dimensional matrices with pointers ... high-class spreadsheets. object and xml databases are more likely to accept the architectures and data models you're working with every day, and are more adaptable, flexible and customizable : you'll be able to apply extreme programming principles and add fields as you go, connect to other systems and maintain focus on your data model and your project, not that of the database and the best possible model that fits into that database. before choosing to ignore this suggestion and go back to relational databases, struggling to fit your designs into its data model, consider xml and object databases. import/export from/to RDBMSs is straightforward, and has been set up in real-time to truly garner the design/maintenance benefits of OODBMSs while retaining the atomicity and existing relational tools without sacrificing data quality and currency. --Grant K Rauscher, freshmeat.net 6/10/2005

Herein lies the mismatch. Relational databases--with their transactional, dynamic and multi-user features--come with functionality that far exceeds what's needed for simply storing and accessing write-once/read-maybe business data. This excess functionality requires sizable hardware and software investments that grow in proportion to the amount of data handled. With costs easily in the seven-figure range, even the most well-funded datacenter would have a difficult time spending its way out of this problem. The answer likely resides in pairing the RDBMS with a complementary technology that is particularly suited to the demands of capturing and storing large volumes of this write-once data. Ironically, a technology previously destined for the history books may well fit current and future requirements perfectly: the flat file. Long relegated to application-embedded databases and desktop programs, a flat file that borrows a key feature from the relational database--the index--meets all of the requirements previously described for digital-business event data. --Kate Mitchell, Rethinking the Relational Database, news.com 6/3/2005

Ian Boyd: I never had to have database design explained or taught to me. It was just so intuitave, so obvious, so simple, that there was no other way you could do it. That's my problem. My brain can't even comprehend the idea of any other database structure design. I'm really looking forward to learning something new [data warehouse], whose fundamental concepts i can't even grasp right now... Adam Machanic: First rule of DW is forget everything you think you know about data modelling... :) --www.mcse.ms 5/27/2005

That's not the only problem with [Pascal's] stuff, but it's one of the more annoying. I purposefully don't read him because he's such a loser. Oh, sure, he's likely right, from a theoretical perspective, but hey fabian, who gives a shit? you're an idiot!!! --r937 aka Rudy, tek-tips.com the only comment i have is that your book is doing you a disservice to suggest avoiding nulls "if at all possible". nothing wrong with nulls (of course, there are a couple of guys at http://dbdebunk.com who would argue, but let's not go there, okay?) let's say you had a brewery for which you did not have an address. oops, can't use nulls, split address into its own table. let's say you had a brewery for which you did not have a phone. oops, can't use nulls, split phone into its own table. let's say you had a brewery for which you did not have notes. oops, can't use nulls, split notes into its own table. see where that's headed? you will need to join five tables just to list your breweries!!! total crap, avoiding nulls. what would you use, empty strings instead? feh, i say. --r937 aka Rudy, MySQL Help, forums.devshed.com 5/20/2005

There used to be a saying about storing data in a normalized database: It makes as much sense as getting up in the morning, assembling your car, and driving to work. Then, at the end of the day, driving home and disassembling your car into its component pieces. The moral of the story was to store data the way you use it. In my opinion, normalization is a process that you go through when developing a logical data model. Once the logical data model is stable, you then develop the physical database design. The physical database design is based on the logical data model, the processes that you are going to automate, and the service level objective that the client has agreed to. If you can achieve the performance requirements of the service level objective without denormalizing, terrific. But if you are having problems meeting your SLO, denormalization may well be the answer. I guess what I am saying is that if the denormalized data is just descriptive information, nice to have on reports but not business critical, then denormalizing it and carrying some small risk of it being out of sync is acceptible as long as it is periodically audited. Medical diagnosis and procedure codes are a good example. The code is the important part...if someone wants to put the description on the report line for each claim, it's not as critical as long as the CODE is correct. --bm1000, sqlteam.org 5/13/2005

Persistence for object-oriented systems is an incredibly cumbersome task to deal with when building many kinds of applications: mapping objects to tables, XML, flat files or use some other non-OO way to represent data destroys encapsulation completely, and is generally slow, both at development and at runtime. The Object Prevalence concept, developed by the Prevayler team, and implemented in Java, C#, Smalltalk, Python, Perl, PHP, Ruby and Delphi, can be a great a solution to this mess. The concept is pretty simple: keep all the objects in RAM and serialize the commands that change those objects, optionally saving the whole system to disk every now and then (late at night, for example). This architecture results in query speeds that many people won't believe until they see for themselves: some benchmarks point out that it's 9000 times faster than a fully-cached-in-RAM Oracle database, for example. Good thing is: they can see it for themselves. --no name, slashdot.org 4/29/2005

Yes, and even earlier system builders concluded that the RDBMS would never fly because it did not let the programmer "navigate". --anonymous, database-forum.com 4/22/2005

Rows have implicit unique row IDs which make each row unique. So, there are no duplicates. --Anonymous Coward, slashdot.org There is no need to import XML in a database in order to run SQL queries over it. You can run SQL queries over everything that is internally structured. Why do you think the S in SQL stands for Structured? I used to run SQL queries on my inventory listings which were connected to CAD drawings... works like a charm. --winchester, slashdot org 4/15/2005

But is there actually a need for a truly relational database? Granted, there are a lot of people out there creating databases and apps on top of them who don't really know what they're doing, but that is beside the point. Just because an inexperienced programmer could more quickly create a useful, reliable app in AppleScript than in C++ does not suggest that C++ is wrong. OK, so this is a poor comparison, but the point is that either way you need to grasp database design fundamentals to make a good, solid database. Not to get really pissy here, especially since my reply is somewhat tardy, but your statement "In any rate, because SQL allows you to create a table *without* a primary key (which then means that result sets can have duplicate rows) then it is not relational. End of story." is complete garbage. Relational does not refer to restrictions that the software imposes on the developer. Any database product that allows a developer to relate a record in one table to a record in another table is relational. "End of story." I can whip up a shitty Python app that satisfies this definition in a few minutes, and just because it isn't a ROFLSTFUIANALIMHODBMS doesn't mean it's not relational. Relational is an idea. Please try to understand that. I don't know where you get your ideas from, but you seem to have a sadly anal (and incorrectly so) way of looking at this. The first real thing I learned about databases was the difference between single-table, flat-file databases and multi-table, relational databases. Can you honestly tell me that what I do for a living is not develop relational databases just because you have such a narrow definition? I do not mean to offend, but I cannot let your statement stand uncorrected. I also apologize for using an "end of story" line in any way, as there often isn't anything definitive about computers or software. --nial-in-a-box, slashdot.org 4/8/2005

The database, relational or not, is the physical entity where data is stored. --CAPCAN, ZDNet.com 4/1/2005

While [SQL products] are relational by definition, they are a pretty simple product. There are other truly multi-relational databases out there that these could never mimic because they lack depth in the relations. --flipper35, ZDNet.com 3/25/2005

I use MS Access quite a bit and it is most certainly a relational database. Relations are set via a graphic interface and while it can a bit complex, it's an efficient system. A FLAT FILE database consists of one table that cannot directly interact with another table. A RELATIONAL database can consist of unlimited tables. The data within these tables can be sorted and edited according to one or more fields within the tables. For example, one table may contain a list of customers (name, adrs, etc) while a related table may list requested shipping dates for those customers. Let's say each customer has an alphanumeric code assigned (this field should exist in each table). With a relational database, the table containing the customer names can be sorted according to the requested shipping dates in the other table. When producing reports, data can be drawn from any number of the tables and compiled into one report, sorted on any field(s) within any of the tables as long as relations are drawn between them. Since various database programs have different methods of creating the relationships, it would be superfluous to get into all that here. Suffice it to say that the result is the same in terms of how the tables interact. Simple enough? After all, what do I know? I'm just a Commodities Relocation Engineer, not an IT guy. --ABB, ZDNet.com 3/18/2005

Webster's has relational defined as: re·la·tion·al ( P ) Pronunciation Key (r-lsh-nl) adj. 1) Of or arising from kinship. 2) Indicating or constituting relation. 3) Grammar. Of, relating to, or being a word or particle, such as a conjunction or preposition, that expresses a syntactic relation between elements in a phrase or sentence. I use MS-SQL and I always thought foreign key constraints fell under the description of "relational". I could be wrong. --Shift4SMS, ZDNet.com 3/11/2005

Good Lord I have heard it all now ... you care to explain why you set a primary key in Access or SQL Server if they aren't relational? LOL someone beam me up! --Terfenol_D, ZDNet.com There you go again complaining about RDBMS's not being "truly relational" without defining what you mean by relational. Maybe the fact that 99.99% of all the developers/dba's consider those products relational should give you a clue. --cicuta, ZDNet.com 3/4/2005

Concept-Oriented Paradigm (Concept-Oriented Philosophy): Concept-orientation is a new paradigm, which underlies such disciplines as concept-oriented programming, concept-oriented databases, concept-oriented analysis and many others. It is based on a set of new general principles, which are different from those currently used in these disciplines. This portal is aimed to collect all information relevant to the concept-oriented approach. The concept-oriented paradigm is based on a set of general principles. In particular, these principles describe what objects are, where do they live, how they are represented and accessed. Although these principle are of very general and even somewhat philosophical character they are quite important for understanding the basics of more concrete mechanisms such as concept-oriented programming (COP), concept-oriented database model (CODM) and concept-oriented design. In particular, these principles are useful in understanding differences from the existing paradigms such as the object-oriented one. --The Concept-Oriented Portal 2/25/2005

Relational databases are one to two orders of magnitude too slow. Big customers have already tried to use relational databases for streaming data and dismissed them. Those products are non-starters in this market. --Michael Stonebraker, Data on the Fly, Forbes 2/18/2005

People usually find relational databases alien and forbidding. The relational model derives from a mathematical conception of data and relationships; it doesn't model or imitate any organizing system people use in real life. If you sat down with a pile of index cards to organize your CD collection you wouldn't choose a relational model. If you sat down with a pile of index cards to organize all of the transactions a typical bank handles every day, you'd give up on the index cards and look for a better solution. If you worked long and hard, you'd invent the relational model. I won't get into the theory behind the relational model, except to point out that few RDBMS implement the relational model completely. Although commercial RDBMSs have a lot in common, each system has quirks and non-standard extensions. You must understand relational theory to correctly design a database -- just learning a particular RDBMS won't get you all the way there. --Greg Jorgensen, Introduction To Relational Database Systems, databasepronews.com 2/11/2005

The goal of the C-Omega type system is to bridge the gap between relational, object, and XML data access by creating a type system that is a combination of all three data models. Instead of adding built-in XML or relational types to the C# language, the approach displayed by the C? type system has been to add certain general changes to the C# type system that make it more conducive for programming against both structured relational data and semi-structured XML data. --Dare Obasanjo, Introducing C-Omega, O'Reilly XML.com (Submitted by Matt Rogish) 2/4/2005

To deliver great reports fast without having to have a team of PhD statisticians pulling all-nighters, Incisix just had to do one trivial, minor, insignificant thing. Scrap the whole "the database is at the heart of everything we do" mentality. To quote the Incisix website: "Stop architecting the database! Applications tied directly to relational databases are costly to develop and maintain and, while once considered state-of-the-art, are by today's standards notoriously lacking in sophistication and adaptability. --Mark Uehling, Reports You Don't Have to Wait for: Incisix, Bio-IT/e-cliniqua (Submitted by Warwick Boardman) 1/28/2005

The new initiative is to re-design much of the current Data Warehouse data architecture with the intent to move away from ERmodeling and demoralization practices and develop a comprehensive dimensional model approach. --4jobs.com 01/21/2005

Project Id: 123015, PHP3/4 + mySQL customer database Qualifications and Experience Required Primary skill: Web Development/Programming Secondary skills: PHP, MySQL Type of website: Retail - Consumer Focused (B2C) Additional skills required: must be capable of creating a well organized mySQL database that will never need to be re-written or re-organized --Job ad, guru.com 01/14/2005

MV databases work well with XML because of already using delimiters to seperate fields, and because of treating everything as a string. As for being the best for everything else - well, it's an easily modified data structure and can be changed to suit whatever reality throws at it, without requiring a major redesign. Which is also its weakness - the programmer has more control and authority than any database designer, analyst, or manager. --Larry Lightbulb, slashdot org 1/10/2005