Talk:Relational database/Archive 1

	Archives
	Current Talk 1 2

This is an archive of past discussions about Relational database. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page.

Archive 1

Archive 2

Archive 3

SQL v relational database

I found this article very imprecise, calling SQL a relational database. It's not informed by the underlying theory, instead taking SQL DBMS vendors claims at face value. I propose to rewrite it entirely, would like to know if anyone has anything against it.

-- LeandroGFCDutra

Go for it. I'd love to see why well-written SQL does not express the relational algebra. --Damian Yerrick

"table" at [1] McKay 09:41, 22 July 2006 (UTC)

It does of course. But I think that Leandro's point is that

SQL violates certain basic principles of the relational model
supporting SQL is regarded by many as not a sufficient condition for a DBMS to be an *R*DBMS.

An important question is here who definese what the word "relational" means. In it's most common use it is used quite loosely and even MySQL is called a relational DBMS. However, many experts such as Chris Date and E.F. Codd insist that the term should be used only for "really" relational systems that are faithful to the theoretical model.

This should probably be explained in the article. Why is everybody looking at me? :-) -- Jan Hidders 22:57 Sep 9, 2002 (UTC)

If, as the article states, a relational database is not an RDBMS, why is it discussing early RDBMSs instead of early relational databases? Vicki Rosenzweig

Wouldn't it be best to redirect this page to relational model (which might even be better off at relational database model)? Jeronimo 07:13, 1 Sep 2003 (UTC)

Rather, the page should be merged with relational database management system, and this page should be a redirect to that. Or the other way round. Both articles talk the same thing. Jay 15:44, 2 Jan 2004 (UTC)

No, no one uses the term "relational database model" A relational database is built in a relational database management system which is a database management system that adheres to (some of the) principles of the relational model. All of these terms deserve their own article. Just like an apple is a kind of fruit that is borne on trees in nature using biological processes. McKay 09:41, 22 July 2006 (UTC)

I have removed:

Relational databases should be processed in normal form.

because, for a relational database, it would be third normal form, that that phrase refers to the normalisation required to create a data model compatible with relational databases to allow the efficient storage of real world data. processed just is wrong or incomplete.

Psb777 08:46, 31 Jan 2004 (UTC)

Progress, www.progress.com, is a RDB and RDBMS and 4gl language set that did not make the list. Thats the problem..."Progress who?". Very stable, around since mid '80s, scalable, faster than Oracle, more secure, less down time, has solid RDBMS administrative tools - unlike many others. pro-ponent.

book by Colin Ritche

Somone has added a book link ("A book by Colin Ritche...") in the "External Links" section. I don't know the book; it may be very nice. But the link goes to Amazon (instead of publisher's/author's site); I feel this kind of advertisement for a specific book store is troublesome. Also: Shouldn't the articles have more content in stead of links, so we don't turn Wikipedia into a link collection? If we start adding books about relational databases, I suggest that the link number be low and concentrated on classics books like [Date: An Introduction to Database Systems] and [Abiteboul et al: Foundations of Databases].

TroelsArvin 07:43, 14 Oct 2004 (UTC)

I've replaced the link with an ISBN number which makes it more book-seller neutral. Although I agree with you in principle (too many not so very relevant links make the article less informative) I'm a bit wary of completely deleting it. -- Jan Hidders 16:58, 15 Oct 2004 (UTC)

Takes the form of a specific collection of data?

This:

"Strictly speaking, this means a relational database takes the form of a specific collection of data."

does not say what I think is meant. Anybody? Paul Beardsell 08:13, 17 Dec 2004 (UTC)

What do you think is meant? What I think is meant is that there is a distinction between some version of Oracle (which is a DBMS) and the personnel database that is kept by a certain company and managed with that version of Oracle (which is indeed a database and not a DBMS). -- Jan Hidders 22:54, 22 Dec 2004 (UTC)

Alright. I cannot work out what is meant. I think the sentence is meaningless as it stands. Someone who understands what is meant should fix it else I will delete it. Jan, I cannot work out how you parse the sentence to understand it as you do. But what you write makes more sense that what is written. Paul Beardsell 19:14, 23 Dec 2004 (UTC)

I have made an attempt. Does it make sense to you now? -- Jan Hidders 00:34, 24 Dec 2004 (UTC)

Yes. Well put. Paul Beardsell 11:24, 25 Dec 2004 (UTC)

What's the subject?

The subject of this article is the relational database. As it points out, the subject is not this or that database software, or even database software considered as a whole. It is the relational database itself, as a concept or model of information management, distinct and separate from any implementation.

This is a vitally important topic and needs to be explained fully. I am ashamed to see so little work here, and dismayed to see squabbling on the Talk page about irrelevancies. Well, it's on my To Do list. — Xiong (talk) 01:37, 2005 Mar 23 (UTC)

Maybe I could help...

This article doesn't make it clear at all

a) what constitutes a relational database (what a rel.db. is) b) what the benefits are

I have a little db. experience, so maybe I could add something, but I don't really know what's best to add? An example? Diagrams? More text (and if so, what)?

I don't think I've got enough experience to basically build a new article from scratch, but I might be able to do something. Shinobu 22:18, 31 Mar 2005 (UTC)

Conversion of this article into a generic hub-intro-overview

JA: As I wander through the bewildering array of articles that are related in one way or another to relational databases, I'm thinking that the present article might best serve as a generic hub for introducing the subject to new readers in the area. I wasn't thinking so much of a disambiguation page, though it could perform some of that service, but a conspectus, invitation, outline, overture, overview, precis, preview, survey, synopsis, whatever word works best for the end in view. Unless I get some contervailing negative feedback, I'll start working along those lines later today or maybe thise weekend. Jon Awbrey 14:10, 9 February 2006 (UTC)

The problem with this article currently is its not accessible. As a newbie to the field, I am having trouble understanding what a relational database is by looking at this article. Explicitly, the definition of "relation" is a bit too esoteric. May be describing it in layman's terms before mentioning tuples would be better. For example "A relation is such and such insert-analogy-or-other-device-here. More specifically, a relation is a set on n-tuples...." Remember folks, an encyclopedia is to cater to the ignorant masses as well as the scholar. ;) -- 127.*.*.1 01:09, 16 March 2006 (UTC)

JA: I added a new front end. Let me know if that helps any. Jon Awbrey 05:46, 16 March 2006 (UTC)

Audience

Whoever rewrites this article--and it needs it--should do so with a naive person in mind. That, after all is the aim of an encyclopedia. The present article is incomprehensible to this audience. Two simple sample tables and how they can be joined would be valuable for this group. Also an RDB should be contrasted with other ways of organizing data (networks, etc.) so the difference can be sensed. Then references to more formal work either within or without Wikipedia for those with such interest. Encyclopedias are like real estate: audience, audience, audience. wgoetsch 18:55, 9 April 2006 (UTC)

adic suffix

I'm not a database expert, but is the suffix adic or radic? I'm just guessing that it's like quadradic. Radix is latin for root; that's why I'm asking.

JA: Monadic, dyadic, triadic, ... are the Greek equivalents of unary, binary, ternary, ... in Latin. It's convenient to use both, especially when binary numbers are lurking in the neighborhood. Jon Awbrey 19:18, 22 April 2006 (UTC)

why relational?

What makes the relational model a good foundation for databases? What advantages does a relational database have over other kinds? Why is it a good idea to normalize a relational database? Ideogram 01:18, 2 June 2006 (UTC)

Merge to relational model

Not my proposal, and I oppose it.

VOTE AT: talk:relational model

Confusing

I'd like to point out that this article is hard to understand. I tried to read it but to someone like me (who knows more than the average person about computers, but not any sort of expert), found this artcule very hard to understand. Perhaps it should be simplified a bit so it isn't so confusng. Speed Demon 22:39, 4 June 2006 (UTC)

Agreed. 203.59.202.179 09:32, 6 June 2006 (UTC)

starting on a rewrite

I intend to rewrite this article. I have a preliminary outline at my user page User:Ideogram. Please feel free to comment here. Ideogram 10:19, 8 June 2006 (UTC)

I have copied my rewrite to Talk:Relational database/rewrite. Please feel free to edit and comment. Ideogram 07:47, 9 June 2006 (UTC)

I'm not quite sure where you're going with this. I agree that the existing article is somewhat daunting for people never exposed to the relational algebra, but what you appear to be writing seems to me to be more of a description of some features which typically are included in database servers commonly called "RDBMSs" rather than a description of a relational database per se. I'm not sure that's right; at best it seems like something which should be a short section of the article rather than the article as a whole. I think the first three sentences of the existing article are correct, quite understandable even to folks without technical expertise, and are the correct direction for the article.

You also have some factual errors, like the sentence, "In the relational model a table is called a relation, a row is called a tuple, and a column is called an attribute." These aren't really equivalent. --Craig Stuntz 13:06, 9 June 2006 (UTC)

There have been several comments here that this article is hard to understand and needs a rewrite. If readers want a mathematical treatment of the relational model, there is the article relational model. For examples of where I want to go with this, see the following links:

All of these articles are superior to this one for a general audience. The 15 Seconds article is the source of my sentence about the correspondence between terms in common use and the formal names. If you disagree, feel free to clarify the differences here (with references, please). Note that I made these same statements in an edit of relational model and since there were no complaints I assumed they were ok. Ideogram 22:24, 9 June 2006 (UTC)

I don't know how to be any clearer: You are writing about something different than what this article covers. I agree with FOo. --Craig Stuntz 03:07, 12 June 2006 (UTC)

This article is a mathematical treatment of the subject and as such is impenetrable to anyone doing a google search of the term "relational database", for which this article is the first returned result. I believe this article is inferior to all the articles I cited above in terms of meeting the audience's needs. Have you read the articles I cited? Can you explain why those articles take an inferior approach to this one? Ideogram 03:14, 12 June 2006 (UTC)

I didn't say they were "inferior" I said you're covering a different subject, as is "Introduction to Relational Database Design". The remaining articles are a hybrid of this topic and discussion of DBs as typically implemented in a commercial DMBS. "15 seconds" is probably the best, but again lists heavily into implementation details. It does, however, do a better job of explaining the theoretical foundation to beginners than this article does presently. These articles are intended to be more or less standalone introductions at a lighter level and breadth than Wikipedia, which is intended to be encyclopædic in scope and is intended to link rather than gloss over or skim details. Yes, the math is dense. Yes, there could/should be a "plain English" explanation. But not a plain English explanation of a different subject. Finally, note that the 15 seconds article does not make the claim I quote and note is incorrect above. It presents an equivalence chart which isn't entirely correct but the terms have a certain analogy. It does not, however, say that tables are the same as relations in the relational model. Your comments express a consistent confusion between what is part of the relational model and what is implemented in commercial RDBMSs, which are not the same. I'd suggest sorting that out before rewriting. Yes, we have relational model which we don't need to duplicate that subject here, but we also have relational database management system which we don't need to duplicate that subject here, either. --Craig Stuntz 15:57, 12 June 2006 (UTC)

(outdenting)Relational database and relational model are not the same. Yet there is a proposal to merge these two articles because of the current overlap between them. Relational database and relational database management system are not the same. But no one is going to type in "relational database management system" into Google to satisfy your prejudices. They are going to type in "relational database" and they are going to get this article and the four other articles I cited, and this article is not going to address their needs while the other four will. Please explain (1) what the difference is between a relational database and a relational database management system, and why my proposed material belongs there, and (2) why you want to present someone googling for "relational database" with a mathematical exposition.

Yes, Wikipedia is intended to present an encyclopedic view of the subject. But the current article is shorter and less informative than all the "lighter" articles. I have no objection to presenting an English language introduction to the relational model. But that should not be the primary focus of the article; as it stands now it is the only focus of the article.

I'm not here to assert facts about the relational model. I'm here to tell you this article doesn't meet your audience's needs. Ideogram 01:14, 13 June 2006 (UTC)

Nobody types anything into Google to "satisfy my prejudices." But however they end up at Wikipedia they must receive verifiable facts. If you feel that people will come here looking for something different than what they actually Googled then it would be far better to have a disambiguation link redirecting them to the correct article than to make this article incorrect, would it not? I think the third sentence of the current article does this OK, but it could be rewritten if you don't like it. And wouldn't it be better to phrase your concerns as personal concerns rather than assertions of my thoughts?

Regarding your questions, (2) is a false premise, as you well know if you have bothered to read my replies at all. Please reread my replies if you actually believe this or can the rhetorical excess if you do not. (1) is the core of my replies above. A relational database is, as the current article correctly states, "a database structured in accordance with the relational model." As I mentioned before, the first three sentences of the current article are actually not bad. A relational database management system is a misnomer category which includes most of the popular DB servers on the market. Calling these "relational" is not strictly true, but we're stuck with the name. Grape Nuts cereal doesn't have grapes or nuts, either, but it's too late to change the name.

I'm not sure why you assert over and over that the article doesn't meet audience needs now when it seems to be the most obvious thing we agree on. --Craig Stuntz 02:32, 13 June 2006 (UTC)

Please assume good faith. Misunderstandings happen.

I have no intention of writing an article without verifiable facts or making this article incorrect. I don't fully understand what that has to do with the fact that my proposed rewrite and this article talk about different things.

When I say this article doesn't meet audience needs I mean that when people google the term "relational database" they are trying to find an explanation of what products like Oracle, SQL Server, MySQL, and PostgreSQL have in common. Trying to explain the theory behind the relational model doesn't do that. Ideogram 04:23, 13 June 2006 (UTC)

First, I'm not accusing you of bad faith; I'm asking you not to put words in my mouth.

The correct place to address the things you're writing about would be Relational database management system. You are talking about specific implementations and not theory. I'm not sure why you are so opposed to putting this information in the place where it clearly belongs. Again, if you think people will arrive here by accident when they actually intend to learn about something different, the best thing to do is to send them to the correct place, rather than making this article incorrect.

To me what you suggest for this article is akin to rewriting Word to cover Microsoft software since people might get there via a Google search when wondering about a word processor, in spite of the fact that the information there has value for its own topic. Thankfully, that's not how it's done. Instead, that software is covered in Microsoft Word, the full and correct name. --Craig Stuntz 14:10, 13 June 2006 (UTC)

I have completed the first pass of the rewrite. Please feel free to edit and comment. Ideogram 09:40, 11 June 2006 (UTC)

If you want to write about RDBMSes, we have an article Relational database management system. Please do not make this article less accurate by introducing factual errors of the sort discussed above. --FOo 23:10, 11 June 2006 (UTC)

A relational database is not an RDBMS. Please explain how this proposed material belongs there. For instance, the article database management system states "Typical examples of DBMS use include accounting, human resources and customer support systems." This is clearly not what I am talking about.

I am fully prepared to discuss any factual errors. If you feel it is a factual error, please explain why, with references, and propose a way to correct it. Simply stating "it's a factual error" is not helpful. Note that I have a reference for my information, cited above. Ideogram 00:30, 12 June 2006 (UTC)

Interesting, perhaps I should have read more of this talk page in more detail before I began. ide, I think that you may understand this better now, but in the DBMS article, saying "Typical examples of DBMS use include accounting, human resources and customer support systems." is techincally correct, though maybe not entirely clear. To explain how this is correct, an example: (like I said, I think you understand this, but others might not, so I'll do the example anyway) Oracle is a PRDBMS, and as such it is a DBMS, one of the most common uses for Oracle is creating the aforementioned systems, or more correctly the backend databases for the database systems. McKay 02:32, 3 August 2006 (UTC)

Yes, I understand that it is correct, I just don't think discussion of those issues belongs in the same article as the material I wanted covered. In any case, I am basically satisified with your rewrite so the point is moot. --Ideogram 02:38, 3 August 2006 (UTC)

starting over

I think we agree that this article needs a rewrite. I think we agree that it needs to be more accessible.

We seem to disagree on exactly what the rewrite should cover. Please keep in mind that my proposed rewrite is a first pass and is not intended to be definitive or complete.

The outline of my rewrite indicates the topics I feel should be covered, to wit: Tables, Primary and Foreign keys, Referential integrity, Normalization, Joins, Indexes, Views, and SQL. Note I am not claiming only these topics should be covered; there certainly should be a section covering the relational model and why no popular RDBMS's today are truly relational; however I am not qualified to write that section.

If you feel my proposed topics do not belong in a rewrite of this article, please explain why. Ideogram 04:31, 13 June 2006 (UTC)

You are asking the same questions over and over again (word for word, in this case), and that isn't going to change the answers. Time to stop talking and start editing. I'm going to work on the existing article since I think it's a better foundation for this topic than your proposed rewrite. --Craig Stuntz 14:10, 13 June 2006 (UTC)

You have not explained to me why theory is the appropriate topic for this article and implementations are not. Note that I wish to discuss both theory and implementation here. I have cited numerous sources to back up my opinion. You have not cited any sources. If you refuse to discuss this matter with me I will be forced to seek mediation. Ideogram 14:34, 13 June 2006 (UTC)

I'm not finding this conversation productive. Are you? It's odd that you would say, "if [I] refuse to discuss this matter with [you]" when I'm the only one who is discussing it with you. But it doesn't seem to be helping to improve the article, so I've decided to put my energy into that instead. We have at least some common ground insofar as we agree that it's too mathematically dense, so I'm going to work on improving that. --Craig Stuntz 14:52, 13 June 2006 (UTC)

I have deliberately refrained from making any edits to the article while we discuss. It is not Wikipedia policy to stop discussions and start editing anytime you feel the conversation is not "productive." If you continue this I will seek mediation. Ideogram 14:59, 13 June 2006 (UTC)

I know of no policy which limits editing while a conversation is going on. You and I both agree the article is too mathematically dense; do you really have a problem with me fixing that? --Craig Stuntz 15:04, 13 June 2006 (UTC)

No, I do not have a problem with that. But I interpreted your words to mean that you were going to stop discussing with me. If that happens, I will feel free to edit until you start discussing with me again. Ideogram 15:08, 13 June 2006 (UTC)

some definitions from the web

google define:relational database

Note the extensive use of the term "table" and the lack of references to "the relational model". Ideogram 04:48, 13 June 2006 (UTC)

the term "relation" does appear in several cases. As does "relational model". Google's definitions aren't guaranteed to be correct, they just find what other people have defined them as. Just because someone doesn't reference relations as tables, doesn't mean that they don't believe it McKay 09:33, 22 July 2006 (UTC)

Codd's definition

Codd's definition is a minority POV, as evidenced by my sources. The fact that he invented the term doesn't mean he owns it. His view should certainly be presented, but it should not be the only view presented. Ideogram 14:47, 13 June 2006 (UTC)

Three of the four articles you present directly cite Codd, and none claim he was wrong. The best of those articles, 15 seconds, makes precisely the same distinction between theory and commercial implementation that FOo and I are suggesting. --Craig Stuntz 15:00, 13 June 2006 (UTC)

All of the cited articles discuss theory along with implementation. I totally agree that the distinction between theory and implementation should be made, and that Codd should be cited. However, I feel implementation deserves discussion in this article. For support, I cite the google search I linked above, in which only one definition other than this one mentions the relational model. Ideogram 15:13, 13 June 2006 (UTC)

thank you for your work

I like the text you have written and feel it addresses my concerns. Ideogram 16:29, 13 June 2006 (UTC)

SQL column order

You might want to mention that writing SQL that actually depends on column order is universally considered a bad idea. Ideogram 16:36, 13 June 2006 (UTC)

While I agree it's considered bad form it's also extremely common and required by the standard. I think a discussion of this subject is more appropriate in SQL. --Craig Stuntz 17:40, 13 June 2006 (UTC)

Fine by me; it's really a small detail. Ideogram 19:23, 13 June 2006 (UTC)

merge notice

Can we get rid of this? It is clearly obsolete. Ideogram 16:50, 13 June 2006 (UTC)

all's well that ends well

I haven't been editing on Wikipedia long and I've already butted heads several times so I must say it is a relief when a contentious dispute is settled peacefully.

I do appreciate that I don't have to do any work now that you are doing it all, but we all know you can do a better job than I ever could. Ideogram 19:31, 13 June 2006 (UTC)

normalization

I would suggest some mention of the practical benefits of normalization. Sorry if I'm getting ahead of you here. Ideogram 19:39, 13 June 2006 (UTC)

You are. :) I just thought it looked wrong to have that section totally empty. Thanks for you kind words, though. --Craig Stuntz 19:44, 13 June 2006 (UTC)

future featured article

BTW I feel this could be a future featured article, but one of the biggest stumbling blocks I've encountered is having enough footnotes/citations/references, so if you could keep an eye out for those, that would be great. Ideogram 20:23, 13 June 2006 (UTC)

Expert needed?

I believe I am an expert on the subject, but there is not discussion page entry as to what needs to be reviewed. I see some information from Relational model has been pulled in, and I don't believe all the information there is accurate either. I've done an initial pass of the mathematical portions. I want to go over this in more detail, and scour through the remaining sections, but alas, it is time for bed. If you have any questions or comments, feel free to ask. My Talk page would be a great place to leave a message. McKay 07:55, 28 July 2006 (UTC)

Drat. Somehow, my changes were lost :( McKay 16:15, 28 July 2006 (UTC)

D'oh! I didn't actually change this article. I changed relational model thinking I Was changing the Relational model section of Relational database McKay 16:18, 28 July 2006 (UTC)

Okay, Ideogram and I had a conversation about this article (on my talk page ATM). It was way past my bedtime, but I worked on it this morning. The proposed rewrite is available at User:Mckaysalisbury/Relational database. Please any comments you could give would be most appreciated. McKay 20:48, 28 July 2006 (UTC)

Okay, User:Mckaysalisbury/Relational database has been been added to, specifically in the areas of normalization and competition. Comments are greatly appreciated, and I will likely move my changes into the real article soon. McKay 23:10, 2 August 2006 (UTC)

I tend to think of indices as implementation details used to enhance performance rather than part of the relational database per se. IMHO an "ideal" database wouldn't have them or need them (and indeed some shared-everything databases do sequential access almost exclusively). Also, per WP:MOS, you only need to boldface the article name the first time it's used, not every time. --Craig Stuntz 00:58, 3 August 2006 (UTC)

I fixed the bolded stuff. I wonder how much I've been doing that in other articles I've written. Also, I tend to agree that indicies aren't part of the database, but I would also say the same thing about stored procedures, views, and sometimes even constraints. I even mentioned this at the beginning of the Contents section, techincally, the database is just a set of relations. I put them in, partially because they are among the things the person in charge of creating the relational database is in charge of, mainly because he is the one who knows the frequent access patterns. Do you really think I should remove it? Any other thoughts on the rewrite? McKay 02:24, 3 August 2006 (UTC)

I think more information is better. I understand that indices are an implementation detail, but anyone looking for practical information about relational databases should know what they are. --Ideogram 02:29, 3 August 2006 (UTC)

Just to make sure I understand what you're saying, by "I think more information is better." you mean to say that you think having the indicies information is good, even though it isn't entirely precise. I think that it's possible that you might mean that the article could use even more information on indices? McKay 02:37, 3 August 2006 (UTC)

Basically I was saying that the section was fine as is, although now that you mention it, it might be nice to say that indices work like book indices in avoiding full table scans. --Ideogram 02:40, 3 August 2006 (UTC)

I read your comment, and thought "yeah, that'd be a good idea", so I went to put it in and it didn't feel right. I did say "the index can be accessed, rather than having to check all of the tuples." So I just added the allegory to book indicies. McKay 02:58, 3 August 2006 (UTC)

I agree with you about procs, views, etc. Constraints I'd be prepared to make a case for, however. I almost categorically disagree with the "more information is better" rationale (why not discuss filesystems, then?), but that's neither here nor there as to whether this material should stay. It might make sense to segregate indices, etc., into a section on "stuff which is not part of a relational database per se but tends to be included in RDBMS implementations." I think indices are the most extreme case of this because they don't change the functionality of the RDBMS at all (unlike, say, views and procs, which you could argue are necessary for real-world use of the software). Regarding the rest of your draft, there are some issues with wording and style (again, see WP:MOS), but I can fix those myself when the article goes up easier than describing them here. The biggest conceptual issue I have is making a clear distinction between what a relational database is and is not. --Craig Stuntz 13:17, 3 August 2006 (UTC)

I agree with you to a certain extent. The way I see it, there are several different "levels" of inclusion.

Relations — Definitelty part of a relational database.
Constraints — Usually considered part of the database, because they are actual restrictions on the data. This could be broken down into several levels itself:
1. Keys — These constraints are an integral part of the system.
2. Foreign keys — These show important relationships among the relations.
3. other constraints — Enforce several kinds of business rules, that could technically be left up to the database system, but are allowed to be included in the DBMS for efficiency, and ease of implementation
4. transition constraints — These constraints havce a tendency to get bypassed, especially in the case of faulty user entry, temporal databases seem to make them more important.
views, stored procedures — These are present in the database, only for common access patterns. They are all completely unecessary except for security, and ease of implementation, and sometimes for funky constraints
indexes (particularly non-clustered, and non-unique indexes) — not really part of the database, but aren't really part of the DBMS either. Usually it is the person creating the database (creating the tables, contraints, views, procs) is responsible for creating the indexes, so it makes sense for inclusion this way.

I don't think we should seperate them into these 4 (7) groups, and it's kinda clunky to mention this in each of their respective sections. Should we (arbitrarily) draw a line somewhere? I don't think that's right. Do you have any other ideas? McKay 16:02, 3 August 2006 (UTC)

Of the options you present I think that mentioning it in the respective sections is the best. Why? Well, any "line in the sand" will be quickly blown away by the winds of well-intentioned editors attempting to correct "omissions." It is better, I think, to explain the rationale of what is and is not part of a relational database than to ignore outlying features altogether. --Craig Stuntz 17:00, 3 August 2006 (UTC)

Oh, one other thing, you mention that views and procs are nececssary for "real-world usage" of the database, and the same thing can definitely be said of indexes, because if there's a table with 40 million rows, and an access pattern outside of the keys (person lookup by name, rather than by ID), this could take hours (or days), instead of seconds (or milliseconds), and such a system is not usable. McKay 16:06, 3 August 2006 (UTC)

I'm discriminating between stuff which is necessary in order to get a usable representation of your data (i.e., things "related" to relational design) and things like performance which are important to users but aren't covered in the relational model or indeed involved in "correct" (per the relational model) data design at all. As a general statement, I dispute the notion that a table with 40 million records is unusable without an index. Tell that to Teradata. The need for indices is an implementation detail of the (very common) design of particular DB servers, not a fundamental characteristic of databases designed around the relational model. The need for humans to design indices is IMHO an unsolved problem rather than a feature. I think indices are roughly equivalent to sort caches insofar as their relevance to relational databases.

The relational model is based around the need for multiple ways of looking at stored data (otherwise flat files would be just fine). Relational databases make these multiple ways of looking at data possible and views implement them. Procs, being generally more flexible, have purposes both within and outside of the relational model, but insofar as procs which can return a result set can do more or less what views do and also insofar as they can be used to make updating data with complex relationships manageable in daily use I think they're part of a "relational database." To say that views and procs aren't part of a relational database is IMHO a bit like saying that a query language or other API for storing / retrieving data isn't part of the relational database. It's true as far as it goes, but a DB which didn't allow you to access, change, or, especially, understand your data would have limited popular appeal. --Craig Stuntz 17:00, 3 August 2006 (UTC)

I think your numbers are a bit off, but I really like the indexless idea for certain applications. Procs and Views are not more flexible, they just store frequent access patterns. Sure they make it more managable (like indexes, or your little continuous access scheme), but they aren't required for relational access. Query languages very much are *not* part of the Database, they are merely what is used to access the database. Query languages are as much a part of the database as the processor instruction set. Essential to get access to the data, but not part of the database. The Relational Database stores data using an RDBMS as a tool, in a similar way that the RDBMS uses the OS as a tool. Yes, A database that didn't allow you to access (...) the data would definitely have limited appeal, but theoretically still a database ne?

Oh, All of this discussion is purely for academic purposes, I love these kinds of debates. I'm planning on adding the descroptions of each group (or variations) to the revision as per your request. McKay 07:59, 4 August 2006 (UTC)

Since we're straying outside of the content of this article, I'll reply on my blog. Thanks for your comments! --Craig Stuntz 14:11, 4 August 2006 (UTC)

The above mentioned changes have been incorporated. What else do you see needs to be done before the integration? McKay 05:07, 5 August 2006 (UTC)