Jump to content

Talk:Database/Archive 2

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia
Archive 1Archive 2Archive 3

true or not true phrase?

"the term database implies that the data is managed" < always? not true. Is manged or was manged, may be managed, will be manged? For example database on CD ("CD Database" = 7,070,000 results). The data data 'is' not manged at all. Is just as is, with no possibility of any management, since is in fixed read only form. Proposed change> "the term database +may+ imply that the data is managed". Eventually the word 'may' can be replaced by other worded conditional statement. 99.90.197.87 (talk) 07:41, 7 November 2011 (UTC)

"The structure of a database is generally too complex to be handled without its DBMS" < there is one circular one false assumption. False: that structure is handled, while it is true, only: too complex database structure is difficult to handle. Circular: 1 the database has already 'its DBMS' 2 can not be without 'its DBMS'. Proposed change >"some too complex structurally databases cannot be handled without a DBMS" 99.90.197.87 (talk) 07:56, 7 November 2011 (UTC)

"A database is not generally portable across different DBMS," < If the database is prepared accordingly to standards can be loaded in plenty of DBMSs (virtually in any). What is not portable are database binary file/device harvested in binary form from memory or storage device. the simplest if one copy data file from MSSQL will not work on MySQL and vice versa. But dumped properly can be ported without a problem to any standard DBMS. Proposed change > A database binaries are not generally portable across different DBMS. Eventually to consider variant of: database binary file, device, binary representation. 99.90.197.87 (talk) 08:08, 7 November 2011 (UTC)

"A way to classify databases... contents,... ... Another .. application area, for example.........." < May give drowned in ...examples... impression of completes which is very false. Paragraph is silent about major division in databases classification: relational databases versus object databases . Most of the article >99%? is devoted to relational and from this 99% most is dedicated to DBMS . DBMS is not a database. DBMS. DBMS has its own article. DBMS is a system used to manage some and not all databases. Proposed change > A cut cluttering examples, B add info contrasting relational databases versus object databases.

As needed much more setup, to move all DBMS related stuff to DBMS article, is proposed too. It will require to turn off some bots since cutting moist of article is needed and such bots will editing work turn difficult. All the software names, divisions: commercial/OpSo and counts, in lede are related to DBMS and not to database so should go bye-bye too. 99.90.197.87 (talk) 08:32, 7 November 2011 (UTC)

I agree that the correct approach is probably to try to move as much stuff related specifically to DBMSs to the DBMS article, though it's likely to negatively impact the quality of that article in the short term. At least some mention of DBMSs has to remain here, though, as while it certainly needs properly sourced I don't think anyone could seriously argue that the two concepts are not deeply intertwined when it comes to contemporary DBs. Chris Cunningham (user:thumperward) - talk 09:00, 7 November 2011 (UTC)
Indeed - the two concepts are deeply intertwined - but the distinction is quite clear thus allowing clear separation of content. The DBMS is management system for database. (If nobody used it for this purpose is obsolete to obscurity). A database is a data collection which *may be or not* managed by DBMS another words may be just a data collection. Some may be confused when DBMS contain word database as 'own' one name. Leading confusion may be Oracle database which is not a 'database' but DBMS. (another example "Borland database"). Of course the DBMS should be mentioned but devoting this article to DBMS will yield tons of false sentences, unless each DBMS related sentence, will specify: it may not apply to all databases or it is particular case or if database is manged by DBMS or.. one can bring here much more examples form current content of article titled database. 99.90.197.87 (talk) 09:50, 7 November 2011 (UTC)
"Database" in prod names usually for historical reasons, before distinction between DBMS and database was made explicit (as in this article now). It also indicates that these prods generate databases. All these prods are DBMSs, of course. --Comps (talk) 16:44, 7 November 2011 (UTC)
I'm not sure it's as simple as that. In the current "Database type examples" section, concepts which relate to databases in themselves are freely intermingled with concepts which are only applicable in the context of a DBMS. Can you suggest how this could be remedied? Chris Cunningham (user:thumperward) - talk 10:04, 7 November 2011 (UTC)
First clear criteria . Since each example has own article list the examples in sentences showing similarities in same group and why are divided between. Wikilinks are solution for all redundant words. If reader understanding (so simple i do it) is goal art should be simple. If keyword reader/keyword - get lost bu us- is goal the more confused the better notion. If example do not have art as its own perhaps not worth to mention at first.99.90.197.87 (talk)
As first approximation we can examine the parts of article where the string 'DBMS' exist to see if context is about database (as data collection) or about DBMS and DBMS aspects of management of data. For example "A database built with one DBMS is not portable to another DBMS" this is rather sentence: "a database entered into one of DBMS is represented in binary form built by this DBMS . Different DBMSes process bits differently and such binary device is not understand (portable) by another DBMS (unless specifically programmed for this purpose{and many can do}). So it is about not about a database but about limits of DBMS. The word database only facilitate here DBMS content. Sqlite may not handle itself Postgress file and will counterproductive to assume one will program such clutter. Otherwise eg. Python (by libs)(or other glue) can open both and move data freely. Such software sentence may make sense from closed view but not from open view. Only obscuring binary data representation closed source may slow OPEN to made all data devices portable and pluggable.99.90.197.87 (talk) 10:41, 7 November 2011 (UTC)
The current Database def includes also all its "binaries". See about defs in special section below. Good luck with your operation. The entire logical structure will collapse, and will need very long and careful repair. --Comps (talk) 16:33, 7 November 2011 (UTC)
Is it for yes or is it for no? And if is for 'yes or no' then what for is it? (in other words: what is correspondence of reply with "the current" about what we plan to make in future ? Do not mess endianness to prove the same database may be of different binaries. iow:101011110101001000110 ? 99.90.197.87 (talk) 04:41, 9 November 2011 (UTC)
As you see in the section I opened below (overlooking this section), I do not think DBMS material needs to be moved, but rather expanded in the DBMS article. I think that here we have minimum material for completeness, confined to a single section of Implementation, with the DBMS article as main. The material should be more elaborated and detailed in a DBMS article. --Comps (talk) 16:33, 7 November 2011 (UTC)
  • "The structure of a database is generally too complex to be handled without its DBMS, and any attempt to do otherwise is very likely to result in database corruption" < [1] ...may interact [with database] by program written in programming language. Contradiction "and any attempt" wrong to "may interact by programming". < Change needed 99.90.197.87 (talk) 10:18, 9 November 2011 (UTC)

Article length

Just to make it explicit and clear: I oppose text movement from here to the DBMS article for the sake of completeness of this article. As I already said, the DBMS article needs to be expanded (possibly using the Implementation section here for text and ideas) to qualify as main DBMS article, rather than cutting this article short; and more:

  1. Pls do not start any "amputation surgery" (massive cut and change) of this kind before a discussion takes place here. I want to see more opinions, and you have to give it time (I do not know the Wiki guidelines).
  2. If the surgery eventually takes place, it will take long time (even with eager busy beavers performing) until stabilizes. I talk from experience: changes are more time-consuming that writing from scratch. Thus, a practical question: is it possible to rewrite it offline, and make a visible Wiki article when mature? This way readers will not be confused with an inconsistent intermediate state.

--Comps (talk) 17:47, 7 November 2011 (UTC)

  • the sake of completeness of this article < to suck the sake: how you define completeness of an article ? This whole website do not aspire to be complete. What about wikilinked / versus redundant? Perhaps the the open universe is less open as such definition, but is curios to see a try. [User 99.90.197.87]
By article completeness I mean a goal not always well defined or achieved, to cover most of the subject in a satisfactory way. This means that experts in the subject will feel that no big holes have been left in the article, as it is defined by its name. I believe the goal of all Wikipedia articles is to converge to such state. This also means that relevant subjects are covered in a satisfactory way. If a main article exists, the text can be relatively short (but still with a good coverage) and point to the main for a more detailed coverage. In our case, since we agree that DBMSs define databases, their coverage needs to be sufficiently detailed accordingly. This is especially true in the current article's structure, where a database is defined by a set of requirements, and the Implementation section explains how DBMS technology meets the requirements.--Comps (talk) 09:24, 8 November 2011 (UTC)
"since we agree that DBMSs define databases"
  • we agree < clearly disagree
  • define < ... word art? de:Personifikation. DBMS rather may help manage: design, query, entry, backup, access,,,(database management system). DBMS is not even needed to use for all databases. DBMS is another article DBMS, another entity. With DBMS one can manage data definition for some database systems, but generalization: "DBMSs define Databases" < if taken literally may be a rhetoric's trick based on fallacy. One good about "expert" which we perhaps can agree: 'the article have to be based on expert sources and (behind section history) current'. If older sources contradict the more current, more current sources have to be used. 99.90.197.87 (talk) 07:55, 9 November 2011 (UTC)
  • the off-line touching quite interesting good idea. It will be good if article can have a two versions. Eg long and short. It will be very good to have article which aspire to be 'mammography of the subject', 'nonography on the subject' ... to 'what about is the subject'. to start, It do not have to be anything programed (but software support my help). The main art database can be changed to list of versions of articles, and the other versions database(1)...n) linked to it. If the readers by vote like/dont_like can positioning such articles with the voting group and the group will be traced then will be easy for reader to find OPTIMUM. Reader can adhere to similar by mental skills, self adjusted level and expertise (OPTIMAL) words facts condensation <for> his knowledge AND across whole domain of articles since randomnes of votes will be autocorrelated to such level of percepted optimum by others<->self. Not sure if Comps authored such idea but thanks for inspire, quite good!. (inpatentcase:da39a3ee5e6b4b0d3255bfef95601890afd80709) 99.90.197.87 (talk) 06:46, 8 November 2011 (UTC)
I have asked a simple question, and you give a long reply that does not answer it at all. Your variations on the theme diverge from an answer, rather than converging to it. I do not want even two articles (and you diverge to n^5 or so with bombastic names...; trying to be funny here by sarcasm and mockery does not help, and I'm not impressed). I was thinking of one article (the old version frozen) plus one work-area "a new version in construction", linked to from the article. Interested contributors and watchers can follow the link and see it. When reasonably mature by consensus it will become the article, while the old with history is concatenated to the history of the new. I do not know what tools Wikipedia has to implement such. --Comps (talk) 09:24, 8 November 2011 (UTC)

Personally I think the article should be shortened: per WP:SUMMARY this article should really be an overview and leave as much detail as possible to sub-articles. Since May 2011 (when Comps started putting a massive amount of work into the article) it's grown nearly fourfold but without significantly changing scope: in a way that's a good thing, as it should make it straightforward to split the new content out to sub-articles. Chris Cunningham (user:thumperward) - talk 10:13, 8 November 2011 (UTC)

"without significantly changing scope" - here I completely disagree, unless by scope you mean the single word "Database": Complete reorg, massive rewrite of (the relatively little) original text (very little left; most of it still needs some work), as you said ~x4 size, and a new expanded lead that summarizes the main ideas: strong connection of database-DBMS ( particularly general purpose DBMS), and defining them by a set of usability requirements (that all existing general-purpose DBMSs posses or converge to). The requirements are well-known and common, but I have not seen them used for the definition (which I believe is the correct way to define). Here I think Wikipedia is unique and superior over other texts (and will be even better...!).
Re length: I believe it will end 110-120K (after expanding what still needs expansion), which is about the recommended length. Given the large scope of the Database subject, I was surprised when succeeded to cover it "so short...": Most needed sub-subjects are covered by a short paragraph, and cannot be condensed any more. Many Wiki articles are 150K+. For example the main article of World War II is ~180K, though different in nature and structure. --Comps (talk) 11:43, 8 November 2011 (UTC)
Where on Earth did you get the idea that the "recommended length" was ~110Kb? The recommended length is 30-40Kb, with exceptions justified only where there is so much well-referenced material that splitting is impractical. We do not simply write volumes of text on a subject until it is so many pages long and then justify the length based on an arbitrary interpretation of its importance to an encyclopedia. Chris Cunningham (user:thumperward) - talk 11:48, 8 November 2011 (UTC)

The current article: Is this a Database article or a DBMS article?

For me this is a Database article. As explained in the article, databases are implemented by DBMSs and thus inseparable. Details of DBMSs are given only in the implementation section. These are minimal detail to make the article as complete as needed, to give a satisfactory explanation how Database requirements are met. I mentioned above that a Database management system article exists, and should be the main one on DBMS, to avoid redundancy in Wikipedia. It is also tagged as Main article in the Implementation section. The DBMS article should be expanded considerably to meet the role of main DBMS article. Some overlap between Database and DBMS articles is unavoidable, and it is OK. But the emphasis is different. the DBMS article should be a substantial expansion of the current Implementation section in the Database article.

This question was asked by an editor, and the above is my answer. --Comps (talk) 15:32, 7 November 2011 (UTC)

I now see that the new section abobe exactly discuses this. I overlooked when writing. --Comps (talk) 16:18, 7 November 2011 (UTC)

What about Database system ? There is (perhaps) union of database itself and it management system; to contain "overlap between Database and DBMS article". 99.90.197.87 (talk) 07:28, 8 November 2011 (UTC)
As mentioned in one sentence in the lead section this term indeed sometimes used by some to indicate a DBMS + its Database. It is a short article, not much beyond the def, and should stay so. --Comps (talk) 09:32, 8 November 2011 (UTC)
So database system is defined (sometime) as database + DBMS. So (sometime) is clear distinction between user Comps preferred current vision of art database and (sometime) defined database. If so it mean that (sometime) database is not what is the current version of art database. If we can agree on |database system "sometimes used by some to indicate a DBMS + its Database"|, then will only remain to find out if our "sometime" is 'very rare', 'rare' or 'not so rare, correct and true' . If user Comps agree (as he already put it:) So the task will simplify itself to research the sources . Some random examples when database system is defined as database + DBMS: pdf. book, ISBN 0-07-352332-1 , Stanford BC 99.90.197.87 (talk) 04:05, 9 November 2011 (UTC)

What should be the definition of Database?

This question was raised by two editors in a previous discussion.

The current definition of a Database in the article is by a set of usability requirements that a database should meet (in order to qualify as a database. This is my opinion). The requirements are very flexible each, and can be implemented in different levels of quality. They are common and well accepted goals for any Database (see modern texts; all that I know). All of them are met to a great extent by all existing popular DBMss in the market, both Proprietary, and Open source. Thus it is logical that they should be met to some degree in order to qualify a data collection ("for one or more purposes...") as Database.

The editors mentioned above would like to have a broader definition. I think that the definition is sufficiently broad, and exactly convey what knowledgeable people mean when they say "database". Any broadening introduces the danger of qualifying strange systems as DBMSs (the requirements are also induced on the DBMSs; a DBMS-Database duality exists), and their data collections as databases. The term Database is often used for data collections that do not qualify for me as databases, and also have been used in names of prods (especially in the past) that very partially meet the requirements, and thus do not qualify for me as DBMSs and their data collections as databases.

I strongly believe the current definition should stay. --Comps (talk) 16:12, 7 November 2011 (UTC)

The problem is, of course, that "(see modern texts; all that I know)" is not really a reliable source. It would be far better to simply pick a definition from a reliable source and state it in the article with a reference to the text in question. The entire definitions section (comprising the lead and the history section) of the article presently contains a paltry two sources, both of which are mostly tangential to that question. That sort of thing is illustrative of the article's current problems. Chris Cunningham (user:thumperward) - talk 10:16, 8 November 2011 (UTC)
I know the subject pretty well, have not seen yet a good source for the def, and thus I'm short of a ref. Original research is forbidden here, and this may be the source of your concern. However almost everybody knows that databases meet these requirements, and a wide consensus exists about this (e.g., show me a general-purpose DBMS that does not have a DDL or Backup: People will laugh if you call its data collection a database). Every database text describes these elements as an integral part of a database (and thus possibly can be used as refs...; some explanation may be needed). Thus just to put the consensus pieces together - I do not consider "original research", though it is original from the point of view of using it for the def. I challenge everybody to find a better definition, and if found, it can be used. This section is the place to discuss it! --Comps (talk) 12:20, 8 November 2011 (UTC)
I'm sorry, but didn't you just say that all of the modern texts you know contain definitions? That's a big part of the problem here: the article presumes that the reader will trust the author to know what he's talking about. We cannot take for granted what "everyone knows" beyond the most banal of facts. Chris Cunningham (user:thumperward) - talk 12:36, 8 November 2011 (UTC)
Not exactly. You would not find direct definitions beyond what you find in the lead here +-. Then you find what DBMSs do, i.e. similar to the requirements here. Database and DBMS are intermingled explicitly and strongly, again very similar to here. So maybe not so original here. People are invited to look into relatively late texts (say, last 10-15 years, and bring their thoughts and quotes. We may be able to reference the def after all without any change here, by pointing out the equivalence to some texts. I have not seen the word "definition" explicitly in texts since too binding, and authors have concerns to be too restrictive. I'm not afraid of the word since the requirements are general and flexible to tolerate large variations. Also the reqs "need to be met to a great extent." Actually also here we can rephrase it without using the word "definition" explicitly (change only where it is used), if a concern, without changing the reqs themselves. --Comps (talk) 17:35, 8 November 2011 (UTC)

The firs sentence is frequent in sources. (and may be the definition) The > 75% in lede is about DBMS. Including all the "prods"(products?). Lets cut at start the DBMS prods. If we move out Oracle (and all other along) out of lede putting the art in shape will be easier. 99.90.197.87 (talk) 07:52, 9 November 2011 (UTC)

sources + quotes (S&Q)

(skip discussion in this section, treat it as ref data base for use in art)

An excellent start. Wherever possible we should base our content on referenced material, rather than writing prose and hoping to fit references in later. Chris Cunningham (user:thumperward) (talk) 10:20, 9 November 2011 (UTC)
  • 4 "A database is a logically coherent collection of related data, where data refers to known facts and have implicit meaning [2] ... Together, the database and DBMS software are called a database system page3 2004 to.see[2]99.90.197.87 (talk) 11:09, 9 November 2011 (UTC)
  • 5 "A database is a structured collection of data. Databases occurred in the real world before computers were invented. Examples of real-world databases include: *Guide to TV programme times *Filling cabinets of documents *Telephone directory page 402 2008
  • 6 "A database is a system to store, retrieve, and organize information. A telephone yellow pages is a database, which stores names and business names and their associated phone numbers. A database management system (DBMS) is a computer application... Dr. E F Codd invented relational database at IBM in 1970. ... A relational database is finite set of formally described tables from which data can be accessed or resembled in many different ways without having to reorganize the database tables. page 6 99.90.197.87 (talk) 11:40, 9 November 2011 (UTC)
  • 7 "The database is a set of files stored on I/O devices. These are typically magnetic or optical disks." page 95 1999 Encyclopedia of library and information science, Volume 65 By Allen Kent
  • 8 "A database is collection of related data" [name, phone#] 89
  • 9 "Multiversion database is inconsistent.. as whole it do not reflect any state of real world." ~..Problem of MVDB... "which versions of different object are consistent together." (about kind of ooDB) page 448 1992
  • 10 "In contrast, an object-orientated database system provides DBMS functionality within an object-orientated programming " page 372 1999 (mainly not on DB)
  • 11 "FBI database is accessed by 13000 agents and analysts through a DBMS ... A database, a DBMS, and the application programs that utilize the data in the database make up a database system" page 387 2010
  • 12 "...a database is a shared collection of logically related data (and a description of this data) ... A data ditionary priovides description of the data..." page 113 2009 99.90.197.87 (talk) 12:25, 9 November 2011 (UTC)

Discussion on S&Q

Here is area about to chose S and draw what to put in art. If one want to put pro versus contra for S&Q please use number to refer to each one. Add another in section above if needed to draw arguments for discussion. Try not use your "head only" words but use pointer to citation for each thesis adding S&Q when appropriate. 99.90.197.87 (talk) 12:25, 9 November 2011 (UTC)

  • Te1: database ,DBMS two separate entity. No ref seem to contradict Te1. Since the refs selection may be (lets assume is) biased; to reject hypothesis put in thesis Te1 other contra S&Q are needed. If Te1 is not rejected, we assume it is true, and shape article accordingly. 99.90.197.87 (talk) 12:45, 9 November 2011 (UTC)

reserearch by Fortune ?

About the ref finally spell out by user Comps. Firstly is good to see it now completed. Now discussion about it reliability and methodology may follow. The results, do they are a original research made by Fortune? (probably GR). How market share were number were calculated. Do the figure include hardware sales and It support (let say yes)? If the hardware and other profits are accounted can this ref stay as is now? Obviously os db to run have to run on some hardware, and its IT cost too . Proposed change < delete all the sentence about software DBMS and move it to DBMS article 99.90.197.87 (talk) 10:39, 9 November 2011 (UTC)

it looks it was good only for one day, why? 99.90.197.87 (talk) 21:19, 9 November 2011 (UTC)

User:Comps suspends his participation in Database

In the last three weeks I have spent more time on the article than in the 6 moths since I started to work on it on May 6 until tree weeks ago. Since I started I have made a reog, rewrite, and expansion, and the article has grown from -26K to ~103K. My intention was to make it a quality article. The last three work weeks I consider useless and a waste of time. This is due to continuous warring against nonsense, to keep the article from being ruined, with people with no understanding in the area (many mistakenly feel experts since databases are all over...), with awkward logic, and with excess time. It also has involved personal attacks on me and my integrity. It is a shame that Wikipedia cannot stop such behavior that causes a complete chaos in the work of developing this article. Until this is resolved I cannot afford wasting more time here, and regretfully suspend my participation. --Comps (talk) 17:09, 9 November 2011 (UTC)

rewrite explanations

"The term "database" refers both to the way its users view it, and to the logical and physical materialization of its data, content, in files, computer memory, and computer data storage. This definition is very general, and is independent of the technology used. " < rewrite

  • data, content, <data content
  • in files, computer memory, and computer data storage< computer data storage consist particularly of files , computer memory, etc
  • "database" refers both < both ? it may refer to many more such ("database" refers..to) verbosed phrases. False duality artificiality limiting diversity.
  • "database" refers both < if refer to different, have to be specific otherwise, will refer to the same. Semantic fallacy by using part of phrase (abbreviated speech) to assuming to whole phrase context . Eg referring to 'physical database' as 'database' is erroneous . If just stated 'database' the receiver can have a idea caller mean 'physical database'. (this explanations are perhaps unnecessary (seem to be oblivious) but due to editing problems are put here to satisfy discussion requests) 99.90.197.87 (talk) 21:15, 9 November 2011 (UTC)

Microsoft Access

It's not mentioned in this article as consumer database management software. 68.173.113.106 (talk) 21:32, 3 March 2012 (UTC)

Just as well. If we start adding every database product ever written, this would get unmaintainable.--SarekOfVulcan (talk) 21:37, 3 March 2012 (UTC)

Database != Relational Database

I think that this article is way off track. A database can be a simple paper folder file storage system, while a relational database is an electronic database that uses relational principles. IMO most of this article should be moved into the article relational database because there already is an article on just that subject. A file system such as DOS is considered a database. An RDBMS such as Oracle is considered a relational database. Why all this overlap? //Mark Renier (talk) 07:05, 26 July 2012 (UTC)

I agree that we should not equate DB with RDB here and I think most of your changes to the lead are improvements. However, it is a stretch to redefine DB to include hard text data stores. The term was coined in the 60's to refer to computer data stores. It is often equated with hard text stores to illustrate for beginning students how a DB works but I think it is a mistake to confuse that pedagogic approach with the practical meaning of the term. Jojalozzo 13:42, 26 July 2012 (UTC)
My point is that when someone says "database", they could be referring to a written log book, as was my personal experience working at the Space Center with old engineers who refused to use those new-fangled computers. The DOS file system is a type of database also. I have also worked with old engineers who insisted network databases were better than relational databases. Of course most folks think today about a relational database when they use the term database, but the distinction still needs to be made. Just because it is not currently en vogue does not mean the meaning has changed. Just because you have not experienced it, these guys are real and this distinction is valid. Please look for some references on this; my old books are out the door and I focus exclusively on the RDBMS Oracle now, but I remember this distinction being made in a book I once had. What about all the RDBMS text below the main heading? Most of this should be moved or migrated to RDBMS, but there is a LOT. How should we start on that? // Mark Renier (talk) 14:23, 26 July 2012 (UTC)
In the section "Database concept" a reference is given to the first utilization of the term. It was not meant in the broad sense you took. Everything includes data and even information, but it does not make it a database. Even an electronic flat file is not a database. You extended the meaning beyond reasonable, and harmed the article. Yes, you gave it a wrong twist.
Also, many DBMSs are not RDBMSs, and many more will be not-relational. 65.96.201.116 (talk) 20:21, 30 July 2012 (UTC)
It sounds like those computer-resistant engineers were using the term tongue in cheek, after it was coined to refer to digital data. As far as I know, it is not a long time engineering term. If you can provide reliable sources to show it has been in use in engineering from before computer data management was introduced I could support your position but until then we should keep this article digitally oriented.
As to the RDB content, I suggest you look to see how much is redundant with the RDB articles. We only need to migrate out what's missing elsewhere. I suspect there is little of that and if that's so, then we need only delete content that is overly detailed concerning any particular type of DB. However, before we do anything we need more input from other editors here. I suspect even our edits to the lead will be met with resistance. If you read back through this talk page (and its archive), you'll see the heaped bones of many who have come before us and that suggests to me that we'll be spending most of our time defending, compromising and reworking the little we've done already. Jojalozzo 15:10, 26 July 2012 (UTC)
Yes, I see no value in what you have done, except making it shorter. You are dropping important info, deviating from the (correct) course of the article, and providing a lead that does not give the right introduction to the article content. Not to mention dropping the DBMS concluding section (see discussion below) 65.96.201.116 (talk) 20:32, 30 July 2012 (UTC)

Yes. "Database != Relational Database" is absolutely correct, and this article is general and applies to all database types. Thus no sense in moving it or portions to an RDB article (you may copy/use relevant portions). It is true that historically much of the development of the area was done in the context of RDB (due to its success and popularity), but also other type existed, exist, and are invented as we discuss. What is written here is also applicable to RDBs, but the general subject of databases (described in this article) is much larger than the specific subject of relational. 65.96.201.116 (talk) 23:31, 30 July 2012 (UTC)

There are more specific articles for a lot of the material in this article. It is more appropriate to move the specific stuff into the specific articles. Database is a less specific (more generic) term that should be a cover article for all of the specific types, each of which have their own article already. Most of the sections in this article already acknowledge this fact by having the section headers that point to the more specific information. Don't do work here, at the more general level, that actually should be at the more specific level. For example, text entries on this article that apply only to relational databases do not apply to network databases; therefore the material is too specific for this article and belongs in the specific article relational database. This article is about database in general; if there is text here that is specific to relational databases, move it to that article, there is already an article just for that specificity. If you do not agree to move specific stuff to specific articles, then we need to merge the specific articles back into this article, because there is duplication of effort in both articles which is not only misleading, it is wrong. In simplest terms, here are the differences. Note that each subject already has their own article. My contention is that somewhere along the way, someone decided to start adding the specific info into this general article, and that the specifics should be moved into those specific articles.

So riddle me these:

  • Q1: Why does this article have material that is only specific to relational databases when there is already an article on relational databases?
  • Q2: Why does the relational database specific material in this article apply to hierarchical databases?
  • Q3: What does this article contain security information that is specific only to relational databases and not network databases?
  • Q4: Why does this article have database design content that could ONLY apply to relational databases?
  • Q5: Why does this article contain information on migration between databases when it there is no way to migrate data from a hierarchical database into a network database?

I could go on and on about how these changes are necessary; please speak up if you want more examples. // Mark Renier (talk) 03:27, 31 July 2012 (UTC)

Further research shows that there is already a wikipedia policy in place to handle this article's content forking. Please move redundant material found in this generic article into the specific articles based on this policy. Thanks. // Mark Renier (talk) 03:59, 31 July 2012 (UTC)
You have misconceptions about databases and relational ones. This article is about Database in general, and has nothing specific to relational database and RDBMS (see discussions below)! This is true to all the subjects dealt with in this article, except specific sections that explicitly specify model type.
Relational is given occasionally as a very important example, but only one among others. The general Database article should be the common denominator to all database types, and include all the material common to all of them. It should and it does! Thus no sense in repeating general material in all the specific database articles. Your logic is opposite to this and does not make sense. 65.96.201.116 (talk) 00:36, 1 August 2012 (UTC)
Stay on track and answer the questions I have posed above. You tried to answer Q1 but you actually are arguing for my point when you stay "no sense in repeating general material in all the specific database articles". I agree, there is duplicated information right now in both articles; moving the specific stuff from the general article into the specific article resolves the redundancy, which is what this edit does: this is ALL specific to relational databases only and the content does not apply to hierarchical nor network databases. You are not insinuating that we move all RDB info up into this article, are you? // Mark Renier (talk) 09:44, 1 August 2012 (UTC)
You do not seem to understand what was said, so it is repeated (also in the discussion below):
  1. In our example, if the general article Database discusses aspects that are common to all database types (which it does), then you do not have to repeat them in all the articles about specific database type, e.g., Relational database, but rather refer to the general (main article; and maybe add a short summary of the relevant text from the main) and write only the info specific to a relational database. According to you, the full texts should be repeated, for example, in both Relational database and Object database. Does not make sense.
  2. In the case of DBMS, the Database article has only a short needed section (to make Database self-contained), while the main article referred to there is Database management system. The latter should cover the intended subject more thoroughly than the section in Database, and indeed needs modification and expansion, to my opinion. However, removing the (minimum) DBMS text (section) from Database and putting it in Database management system ruins the Database article. You can copy relevant text from Database and expand it in the Database management system article, or write/modify whatever text you would like, to improve it as the main article for DBMS. 65.96.201.116 (talk) 15:39, 1 August 2012 (UTC)

This is a good Database article (and users give it good ranks). I have been teaching Databases for years in Academia, and this article is the best summary I know. You (Mark Renier) know SQL and maybe more database material, but you do not seem to get what this article is about: It covers at a very high level almost the entire database space, and quite well. Some sections may need expansion and enhancement, but almost none can be dropped without harming the article's completeness. If you can add anything important, it would be nice, but to start tearing it apart is really bad. On the other hand, other WP database articles' quality is not satisfactory, and if databases are your passion, you can put your efforts there, and try to improve them. Regarding your new tag comment, condensing was requested for number of named sections, and not for content. I think that the multiple sections in the TOC and hierarchy help a great deal in reading the article and looking for a specific subject, and thus this tag is completely unnecessary and can be removed. Also your tag is unnecessary: This article is not a random collection of links, as you describe it in your tag comment. This article is well built, with a very logical order that cover well a huge space of many dimensions relevant to the general database subject. 65.96.201.116 (talk) 16:46, 1 August 2012 (UTC)

Should the DBMS section be removed?

Not to my opinion. This is an important part of the Database article, and provides a very short answer to how the Database requirements, the subject built in the first sections, are met. This answer, conclusion, should be an integral part of the article.

It is perfectly OK to enhance the DBMS article (Database management system), and even to copy text from the Database article if helpful, but is is a big mistake to harm the integrity and completeness of the Database article. In the DBMS article the copied text should be expanded and elaborated. 65.96.201.116 (talk) 20:05, 30 July 2012 (UTC)

No, it is NOT "perfectly OK" to copy text from one article to another. A wiki link should be used to point to the "home" article. What you are proposing is handled under WP:CONTENTFORK, which specifically states that this is to be avoided. //Mark Renier (talk) 03:43, 31 July 2012 (UTC)

Yes, move it! DBMS section is specific to relational databases only, and not to object databases, database management systems, hierarchical databases, nor network databases. In fact there is already a whole separate article JUST for that subject. Standard wiki procedure is just to include a single paragraph on how that article applies to this article, with a section header that points to that information. Right now it is a mistake because the article duplicates information already found elsewhere. // Mark Renier (talk) 03:33, 31 July 2012 (UTC)

1. You are totally mistaken and uninformed: The DBMS section (erased by you) is general and applies to all database and DBMS types. I'm am a long time database professional with knowledge of the history and internals, and state the above with confidence.
Thanks for addressing the point head-on. I too have some db experience. Please tell me, then, sir, with your high confidence level, how a network database uses a query optimizer (here) when it does not use SQL? How does a materialized view apply to a hierarchical database (here) when it does not use SQL? The answers are that they don't, because they are specific to RDBMSs and OODBMSs. Therefore, the material that is this specific needs to migrate into the specific articles. // Mark Renier (talk) 10:15, 1 August 2012 (UTC)
You are mistaken again:
Query optimizer: Other data models use other languages, but in all models alternative access paths exist for each query. The role of the optimizer is to find the best path (usually an approximation to best) for a given query. It is needed in every model, though, of course the optimizer relies on the specific paths possible in any specific model in any specific DBMS implementation (heavily relies on the physical model).
In the network database you can answer the same query by traversing the Set constructs in different orders. The optimizer finds the alternative that minimizes direct (random) accesses and maximizes sequential access.
Materialized view (of a query) is a data layout (redundant to the database's original relevant/matching data, and different from it in layout) that allows to compute a given query very effectively (derived from an output of an optimizer). When you have the materialized view you can compute the query much quicker than computing it with the native database data. This is independent of model and language and useful in any DBMS type.
A materialized view of a query in the hierarchical model arranges the needed data in a hierarchy different from the original hierarchy (a different data chunk from the original) in a way that computing the query is done mostly sequentially along the new hierarchy levels (while in the original hierarchy, many jumps among hierarchy levels, direct accesses, are needed).
Comment: In conventional disks sequential access can be faster in orders of magnitude than direct access. Thus optimized queries often execute orders of magnitude faster than their straightforward execution without optimization. 65.96.201.116 (talk) 22:58, 1 August 2012 (UTC)
2. You generated this copy and duplication with your own hands (in the DBMS article), and you have to repair this. If you think that the DBMS article is missing, and you do not want to copy, then write your own piece and do not copy from the Database article. And more severely, after copying it you claim that the original is a copy and then erase it!!! your logic is also beyond comprehension, and I wonder how many WP rules you break here. Pls return the "stolen" copy! 65.96.201.116 (talk) 19:04, 31 July 2012 (UTC)
- You again reverted with no explanation, and without answering my comments. You have misconception about the area of Database, and to my opinion severely harm the Database article. I doubt if your methods of enforcing (incorrect) opinions get even close the WP guidelines. If you want a change for an issue under discussion please participate in the discussion, and do not enforce the change without discussion conclusion.
- WP administrators, please take a note of the behavior of Mark Renier, and guide him.
- People with knowledge about Database please provide your comments and opinions. 65.96.201.116 (talk) 20:57, 31 July 2012 (UTC)
Coming from somebody who does not use a standard wiki account, this is rich! There was an explanation, and in fact it's called a standard wikipedia policy called WP:REDUNDANTFORK (you have to look in on the comment line of my edit to see that link). To everyone else, yes, please guide me. Please address the questions on this page that I have posed in order to make me a better editor. Right now I am seeing lots of standard wikipedia policies in question, that keep getting reverted by other editors on this article. Note that it is the person who REVERTS an edit that starts an edit war, not the editor trying to make the changes. Any revert that I have posted is backed up by a standard WP link on this page. I am not seeing the same results out of other editors here. // Mark Renier (talk) 10:15, 1 August 2012 (UTC)
You do not seem to understand what was said, so it is repeated:
  1. In our example, if the general article Database discusses aspects that are common to all database types (which it does), then you do not have to repeat them in all the articles about specific database type, e.g., Relational database, but rather refer to the general (main article; and maybe add a short summary of the relevant text from the main) and write only the info specific to a relational database. According to you, the full texts should be repeated, for example, in both Relational database and Object database. Does not make sense.
  2. In the case of DBMS, the Database article has only a short needed section (to make Database self-contained), while the main article referred to there is Database management system. The latter should cover the intended subject more thoroughly than the section in Database, and indeed needs modification and expansion, to my opinion. However, removing the (minimum) DBMS text (section) from Database and putting it in Database management system ruins the Database article. You can copy relevant text from Database and expand it in the Database management system article, or write/modify whatever text you would like, to improve it as the main article for DBMS. 65.96.201.116 (talk) 15:20, 1 August 2012 (UTC)
Your last revert meanwhile disappeared including its history line. I do not know what "magic" was used, but let it be... 65.96.201.116 (talk) 21:09, 31 July 2012 (UTC)

Should the article direction be changed and the lead section cut short?

The article has been advocating the idea that "a Database is a collection of data managed by a DBMS" to meet certain quality requirements. This is the idea supported in all the database professional text books that I know. This idea has evolved since the database concept came into use. Some people use it in more general ways, where the extreme approach calls a "database" any collection of data. This is simply incorrect according to the people who invented the concept and the people who do development and research in the area. Generalized use may deserve a sort comment in the article. Changing the article to take this general view is misleading and a mistake. 65.96.201.116 (talk) 21:11, 30 July 2012 (UTC)

The "Broad concept" tag is incorrect , misleading, and should be removed

The tag includes the following text:

"This page appears to be a broad concept improperly framed as a collection of ambiguous links. This page should be converted into a list or article covering the general topic which is the primary meaning to which these links relate; any truly ambiguous links should be moved to a separate page with "(disambiguation)" in the title."

This text is incorrect and misleading:

  • "collection of ambiguous links" - Nothing is ambiguous in the links presented, This is a well thought article, with very clear and proper links that well support the article and extend it to a full text-book on the subject.
  • "This page should be converted into a list or article..." - This is an excellent Database article, that best database summary I know, and I find this sentence out of line. I cannot imagine even what misconceptions about databases guided writing this sentence.
  • "any truly ambiguous links..." - No link in the (long) article I find ambiguous (or "truly ambiguous"), and I cannot see any relevance or logic, or value here.

The only agreement I have here is about the term "Broad concept."

Though the article may need some enhancements and expanding in (few) empty sections, it is in general very good, well describes this complex and broad subject in a logical way (even the TOC is useful as a directory), and useful to anybody who is interested in databases. It is a good introduction which provides a broad view of the subject. Following the links (including main articles) readers can get dipper into specific sub-subjects.

I have taught databases in Academia for many years, and would recommend to my students and others reading this article. This improper tag should be removed. 65.96.201.116 (talk) 13:58, 2 August 2012 (UTC)

 Done - {{dabconcept}} was really inappropriate here as it only applies to disambiguation pages. I have replaced it with {{toolong}}, which I think better conveys the intention of the original tagger. The template text was indeed misleading, so I changed that as well. --M4gnum0n (talk) 13:47, 8 August 2012 (UTC)

Multiple tags discussions

The article has accumulated several tags. Please do not apply changes related to subjects under discussion.

  • This article needs additional citations for verification. (December 2011)
I agree, however see a (solvable) problem here: Much of the material here is general and covered in general database text books. It does not make sense to reference every related fact. Thus a group of general text books in the references should suffice. Some specific facts deserve numbered footnotes, and some such already exist.
  • This article may have too many section headers dividing up its content. (November 2011)
I do not believe that it is "too many." I think that given the wide scope of the subject, comprising many distinct areas, it is important to have a clear distinct section for each area, even if very short. Merging such sections will increase confusion and reduce readability. Dropping sections will severely harm the completeness of the article. In this respect the article is quite different from other Wikipedia articles. The automatic hierarchical TOC in Wikipedia substantially helps in viewing in a glance the structure and logic of the article when sections are explicitly marked. The article can be conveniently be read either sequentially, or by "direct access" from the TOC to a desired sub-subject.
On a second thought, some sections may be merged while a section is replaced with a bullet. The downside: Such is not shown in the TOC, which makes it less transparent in a glance. 65.96.201.116 (talk) 15:43, 17 August 2012 (UTC)
  • This article may be too long to read and navigate comfortably. (August 2012)
Do no agree. The article is relatively long, but not too long. It includes quite minimal text (some yet too little) needed to adequately cover this complex subject (in the sense of number of components needed even to properly define it; most other texts I know do not give good coverage even when much longer; short database article typically do not give proper coverage). The logical partition into hierarchical sections and the TOC help in readability (see also section above).
  • This article's introduction may be too long for its overall length. (August 2012)
Do not agree, though paragraphs may be merged to reduce paragraph number (if a concern at all). The lead section quite well gives an idea about the article's content, while explaining the subject's importance. Relatively to the quite long article the lead is not long at all. Thus it does its job well.

65.96.201.116 (talk) 21:12, 16 August 2012 (UTC)

Premise: this article is a giant hairy mess and would deserve a lot more tags. Regarding the ones already put at the top of the page, I disagree with nearly everything you have written above. Being a very broad concept is not an excuse for an extremely long article, nor for an excessively fragmented one. I will point you to a guideline and an example. Additionally, I would like to point out that, not only are there too many sections, but they also seem to be randomly placed. --M4gnum0n (talk) 09:18, 17 August 2012 (UTC)
Your Universe example is a beautiful article. The Universe subject is much broader, of course, than the Database subject. With that said also the Universe article is a giant hairy mess that deserves a lot of tags. It looks as a random collection of many sections, dealing with many aspects of the concept, and yet I'm not sure whether the Universe subject is satisfactorily covered.
The Database article is not a random collection of subjects. It has a very logical order (I can justify and detail, if necessary), and well covers the area from the technical point of view. Of course it is not the only possible database article, but I can hardly see how by merging sections you make it more readable, or by dropping sections' info you do not harm its completeness, and not turning it into a more superficial article. 65.96.201.116 (talk) 15:24, 17 August 2012 (UTC)
A second thought: Some section may be merged and replaced by bullets. See also above.65.96.201.116 (talk) 15:43, 17 August 2012 (UTC)
Well, I really don't know how to start with this, but the main point is: NO, this is an awful article. Its structure is not logical at all, to the point where it is shockingly so. I could make examples, but almost everything is displaced! So, really, it seems useless to me if you do not see it yourself. And this is only one problem.
Well, except "awful article" you have not said much. Regarding the "shocking" article's logic it is as follows by the top-level sections:
  1. The database concept history is discussed with its major points as subsections, including the crucial relationship between a database and a DBMS. It well provides the modern definition of a database by a set of requirements to be met by a data collection to comply as a database.
  2. The diversity of the concept is demonstrated by multiple major classes/types of databases that have been dealt with through history and play important roles in today's databases (a quite exhaustive list). These classes/types apparently look completely different, but all have to comply with the definition requirements to a great extent.
  3. The list of consensus requirements that define a database is outlined.
  4. The major areas that have been the focus of research and development are outlined.
  5. The DBMS section answers how the requirements are met in practice, and how the major area subjects are implemented - a conclusion. The respective DBMS main article should cover the DBMS subject in a more detailed way (and drop much text that is not directly relevant to DBMSs (systems), but rather quite well covered by the Database article).
Every section is well divided to the most relevant subsections, and the article provide a quite complete, very compact picture of the database broad area.
This is a very logical order for sequential reading, where any given article prefix serves as a logical introduction to the current point of reading. As well it is a great help (using the TOC) to access a specific subject, and from it to access the respective main article(s).
I challenge you to propose a better order and logic, beyond saying "awful," which is not helpful at all. 65.96.201.116 (talk) 04:21, 1 September 2012 (UTC)
Again, I will point you to WP:SUMMARY, which you should carefully read. It explains, among other things, why a broad-concept article like "Database" is required to be superficial. And finally, replacing section headers with bullets does little to address the issue, as it does not alter its composition. --M4gnum0n (talk) 14:40, 30 August 2012 (UTC)
The WP:SUMMARY article is very helpful, and I find that the current Database article complies with it. If you see contradictions, pls be more specific. 65.96.201.116 (talk) 04:21, 1 September 2012 (UTC)

I think it's a pretty poor article. It seems to ramble around the subject with no sense of direction or purpose; and it seems to have little sense as to what information is important and what isn't. It seems to be written by people who don't have a clear picture as to who they are writing for - who is the reader and why are they reading it? It's not an easy article to write so I don't blame anyone (and if it were easy then I would try to do better). I've been tracking it for years and (quite apart from the high level of vandalism) many of the contributions seem to be by people with a very weak grasp of the subject - I suspect from students, perhaps even schoolchildren. The lack of citations doesn't worry me too much since most of the facts are uncontroversial. So I can't propose easy answers, but please don't delude yourself into thinking that it can't be improved. Mhkay (talk) 17:52, 2 September 2012 (UTC)

My impression of the article, contrary to you:
  • "pretty poor article" - I disagree
  • "no sense of direction or purpose" - Purpose: Explaining what a database is. Direction: Explaining the concept and covering the main subjects that database development and research have been dealing with along history, in a logical order.
  • "what information is important and what isn't" - All the information here is important for reasonable coverage of the subject. Dropping any subject covered will leave a hole, and subtract an important sub-area. Many superficial database articles exist; this article is special in its exhaustive coverage of the important concepts and sub-areas that comprise the database subject. The database concept has evolved into a quite complex one, with many dimensions, and all its major aspects need to be dealt with for a reasonable coverage. Nothing to do about that, if accurate and good description is desired, like here.
  • "who is the reader and why are they reading it?" - Any reader: from the beginner who never heard about a database, to an expert (even in databases - you) who may know some trees, but get lost in the large forest... It well covers at a high level and in short the most important database areas.
  • "I've been tracking it for years ... (written) by people with a very weak grasp of the subject - I suspect from students, perhaps even schoolchildren" - I have to completely disagree here: I do not know much about the article's long history, but now I find it accurate and to the point, showing excellent understanding of the subject. Language can be improved in some places. I do not care if written by kindergarten pupils. Pls give at least one example to support what you say. The article may include old database type examples (old text?) that need polish (operational, multimedia, and possibly more), and a strange section about "other models." Anything else I have seen (besides possibly minor language; as far as I now remember) can be easily fixed without a major change in the article.
  • "please don't delude yourself into thinking that it can't be improved" - I never thought it could not be improved. I'm sure it can, like almost everything, and any improvement (versus harming...) is welcome. I'm sure that many minor incremental improvements should be made. I do not see major faults, and so far nobody here showed such, except generalities and negative adjectives. To make a critique effective one has to point to concrete faults and bring concrete suggestions for corrections. Otherwise I find a critique quite worthless.
I'm just trying to protect article/material that I consider good quality and very helpful to general audience. Any good concrete suggestions for improvement should be implemented. But they have to show first. 65.96.201.116 (talk) 07:06, 3 September 2012 (UTC)


Well, firstly, there's a lot of poorly-written English. Almost every sentence suffers. Here's one chosen almost at random: "Accordingly its supported data collection needs to meet respective usability requirements (broadly defined by the requirements below) to qualify as a database." I know what it's trying to say, if only because the article says it about four times in different places, but it's a very inelegant way of saying it. Here's another example: "The database concept has evolved since the 1960s to ease increasing difficulties in designing, building, and maintaining complex information systems (typically with many concurrent end-users, and with a large amount of diverse data)." That's jus muddled thinking. How do you ease a difficulty? Why have the difficulties been increasing if database technology has been easing them? If the concept has evolved, then what was the concept at the beginning and what is it now? Almost every sentence raises more questions than it answers, mainly as a result of convoluted prose.

  • "poorly-written English" - Language can be improved locally, without turning the article upside down. Any improvement is welcome. Should be done carefully without distorting content, which I often have seen in technical material, when content is not completely understood when changed. I think you are exaggerating in your inability to understand the content in some examples above, and can hardly believe you.
  • "...Muddled thinking. How do you ease a difficulty?..." - "How you ease" is explained in the entire article, not in short after the claim. It is eased by DBMS functionality which meets the database requirements outlined. The concept from the beginning was a framework to help ease the task. The details have evolved in time, and it took years to explicitly put the finger on, and to formalize the set of requirements.
  • "Why have the difficulties been increasing if database technology has been easing them?" - What I read: The difficulties have increased as information systems became more and more complicated (I was there...). Databases evolved gradually and started to solve more and more problems. It took time. The first version of the "first DBMS" did not have today's DBMS functionality. I see understanding problem here (muddled thinking?). 65.96.201.116 (talk) 16:32, 5 September 2012 (UTC)

Secondly (as noted) there's an awful lot of repetition.

  • Personally, I find controlled and balanced redundancy desired, especially in articles consisting of many sections and subsections. I hate to waste time on going back in sections to look for a definition or context from previous sections I would like to review. Also may be needed in direct access (to a section) reading mode, for self containment of a section. 65.96.201.116 (talk) 16:32, 5 September 2012 (UTC)

The article ties itself in knots dealing with the difference between a database and a DBMS. It's not difficult, why make such a meal of it? A heading like "Evolution of database and DBMS technology" just raises questions and complications - there's no difference between database technology and DBMS technology.

  • There is a difference between what is required, the needed database functionality, and how it is implemented by a DBMS, and the article nicely makes the distinction. Of course, they have evolved jointly, in two parallel paths. The database part deals with satisfying (what are the needed solutions, functions) external applications' functionality (the application supported by a respective database); the DBMS part deals with the techs needed to build the DBMS itself (how the proposed solutions are implemented). 65.96.201.116 (talk) 16:32, 5 September 2012 (UTC)

The long list of "database type examples" is dreadful. It's a bucket into which random odds and ends have been thrown. There's no attempt here at a coherent taxonomy, which is probably why the word "examples" has been added.

  • "dreadful" - I find the long list very useful: These are the database types that have been highlighted in research and development along database history. They almost all demonstrate legitimate and often useful database types though may completely differ in nature. The list comprises a good section to prepare for showing how the database concept unifies them all. Ordered alphabetically is nice, since types are multidimensional and cannot be listed along a single dimension. I find "dreadful" really exaggerated. 65.96.201.116 (talk) 16:32, 5 September 2012 (UTC)

The overall structure is totally illogical. Why is "Types of people involved" a subheading of "History"?

  • It is logical: I have explained the overall logic somewhere above, and you choose to ignore what I have said (may you comment on this, rather than opening it anew?). "Types of people involved" is an important subsection of general purpose DBMS which is a crucial part of history. A complex general purpose DBMS would not be possible without a clear division between different people types involved with it. Its location looks the natural place. 65.96.201.116 (talk) 16:32, 5 September 2012 (UTC)

Then we get a list of "functional areas": "The functional areas are domains and subjects that have evolved in order to provide proper answers and solutions to the functional requirements above." A vain attempt to provide coherence to a structural ragbag.

  • "A vain attempt..." - Why vain? It is a very successful attempt: These areas are the main areas dealt with in all database texts. I find your claim quite strange, to say the least. The section that contains the subsections of the areas is properly located after the requirements list to show the answers to them. It is coherent, and I completely support the location and list. 65.96.201.116 (talk) 16:32, 5 September 2012 (UTC)

So: you asked for a critique. In summary: (a) the structure is very poor, (b) the writing is very poor, (c) there is a lot of repetition, (d) it's too long for its purpose. The saving grace is that most of the facts are correct and the opinions uncontroversial. Mhkay (talk) 22:42, 3 September 2012 (UTC)

  • (a) I do not think so: see above. Pls show a better structure, if you can! (b) Pls correct where you can improve. (c) See about redundancy above. (d) The article looks to me minimal and concise. You cannot shorten sections much. Dropping sections or sub-sections will harm the completeness and remove important dimensions of the subject, making the article superficial.
  • "The saving grace is that most of the facts are correct and the opinions uncontroversial." - I'm glad to see that we agree on this! "most": Pls exactly show if you think incorrect anywhere.
  • It is easier to destroy an article than to build a good one. Thus, usually it makes sense to make incremental improvements, rather than tearing an article apart. I think this is the case here.65.96.201.116 (talk) 16:32, 5 September 2012 (UTC)

It's a shame that you are so reluctant to listen to constructive criticism. Listening to critics is how people improve. Mhkay (talk) 22:14, 13 October 2012 (UTC)

I'm quite puzzled by your reaction: I "listen" to every word, and write my opinion on it. I do not ignore you. I mostly disagree with your comments, and say it explicitly with no shame. What is wrong with this? My answers above provide you with a large space for action (e.g., suggesting new structure as you want (logically here, so we can discuss its pros and cons), and possibly improving language), but I see none. 65.96.201.116 (talk) 23:25, 13 October 2012 (UTC)

Sorry, but I don't see any point in attempting to improve the article myself. I would start by changing "data" to be a collective singular, which is almost universal usage in computer books (if it's plural, then it makes sense to ask "how many data are there in your database?"), and someone (you?) would immediately revert it. I've edited this article to improve it in the past, and the improvements have disappeared within months.Mhkay (talk) 16:03, 19 October 2012 (UTC)

Why don't you respond to the detailed comments or bring a proposal before "attempting to improve the article myself?". 209.144.63.76 (talk) 22:40, 5 December 2012 (UTC)

I concur with Mhkay in that this author just not listen to criticism. He's using Wikipedia as if it were a means to publish a book. This is no place to publish books nor scholarly articles nearly as much as articles with ENCYCLOPEDIC knowledge: you reduce your big subject matter into a few dabs here and there in a short, concise article. Frankly, if you cannot do that, then Wikipedia is not the place for you. Go publish elsewhere. Just because the subject is large, complex or important does not mean an encyclopedic article about it has to be. If you cannot summarize effectively, don't blame the subject matter: blame yourself for being so brain-bound (like muscle-bound) that your subject matter has command over you instead of you having command over your subject matter. Your replies to everything on this page only proves your inability to listen and understand any way other than your own.

The answers there make sense more than what you write. 209.144.63.76 (talk) 22:40, 5 December 2012 (UTC)

This article is huge and does have too many sections to be an ENCYCLOPEDIC article about databases, more that just a cutout from some textbook about databases that you like so much. All you want to express about a topic that you worship so much could have been better accomplished by an overview article about databases, and then a number of well-written detailed articles that relate nicely to this overview article and support and be supported by it, instead of cramming it all into a single article, and so derived articles look a lot more repetitious than they need to be. Finally, remember: the key word is ENCYCLOPEDIC. Not thorough, not super complete. That is for textbooks. Not for Wikipedia. — Preceding unsigned comment added by Lamp90 (talk • contribs) 05:53, 23 November 2012 (UTC)

Whoever "this author" is you do not make much sense:
ENCYCLOPEDIC: Wikipedia is supposed to be (and is!) the encyclopedia. It is not a superficial encyclopedia to elementary school pupils. You ideas about "encyclopedic" are really funny. See for example other major technical/scientific articles like Calculus and General relativity. Do you suggest to make them shorter and remove there technical material that you may not understand? By your criteria for "encyclopedic" both Wikipedia and others like Encyclopedia Britannica with probably shrink by at least 50%.
TEXTBOOK - This article is roughly 100K char long. Have you seen any database textbook? I know a few and they are larger in orders of magnitude! Typically hundreds of pages long. So, what are you talking about? 209.144.63.76 (talk) 22:40, 5 December 2012 (UTC)

Where vacuum exists in the Atmosphere, air is sucked in. Where vacuum exists in Wikipedia (lack of active experts), the clueless and illogical are sucked in (I'm trying to be polite...). Databases are very common. Everybody is familiar with the term, and too many are not aware of the extent of the area and consider themselves experts. It includes many areas of expertise, and a non expert should not mess with article text's meaning. I checked and found that the article was bad until mid 2011, and then got a good boost by experts. However, they do not seem to be active lately, and the clueless try to takeover, unaware of the harm they can cause. Some tags are unnecessary, and many comments here do not make sense. 209.144.63.76 (talk) 23:03, 5 December 2012 (UTC)

What about the X.500 Data Model?

At the risk of further complicating an (apparently) already overly long article, I find myself wondering why the hierarchical X.500 data model is not described here among the major database types. Unlike the original hierarchical DB developed at IBM, already listed on this page, the X.500 model is still alive and well, and a key part of most network infrastructure around the world. Highlandsun (talk) 16:08, 11 October 2012 (UTC)

Indeed in a comprehensive treatise there would be some justification in including it. But we ought to be saying less, rather than more; we need to focus on what's most important. X.500 as a data model is interesting, but it's only really a variation on the "hierarchical" theme, and although in principle it is general purpose, it has never really made an impact (or tried to do so) outside a niche application area.Mhkay (talk) 22:18, 13 October 2012 (UTC)

X.500 is not a DBMS data model. It is a series of computer networking standards covering electronic directory services. It is true that it involves a data model, and its implementations require some (embedded) DBMS technologies, but it is out of the general Database realm. This article deals with the major subjects pertain to databases and the major milestones in this area. In particular it does not cover the almost countless special cases of database (or "almost database") utilization. 65.96.201.116 (talk) 23:53, 13 October 2012 (UTC)

Beginning

What is that line at the beginning of the article. "See mostly erased Talk:Serializability#Commitment_ordering discussion. User:Ruud Koot lying about User:Comps sock puppets. User:Ruud Koot is also an idiot: good science wins eventually. 209.117.47.248 (talk) 21:30, 11 December 2012 (UTC)" Jedieaston (talk) 21:58, 11 December 2012 (UTC)

Weasel words

This article, at least the summary, uses lots of weasel words like "often" or "especially" — Preceding unsigned comment added by 12.233.9.72 (talk) 19:37, 23 January 2013 (UTC)

Spinning off new article

The "Database type examples" is quite long. Perhaps there could be a general summary in this article, with the detailed descriptions given in another linked article. I would be willing to do it. Shandong44

Does not seem to be necessary or useful. Section is relatively long, but with many short bullets (as needed to cover the major types) with references to main articles. 209.144.63.76 (talk) 22:07, 5 December 2012 (UTC)
Some examples could be combined with other sections, like "Data model" and "Database languages". -- Beland (talk) 07:42, 16 March 2013 (UTC)

Length

Well, I managed to get this article down from over 100K to around 56K by eliminating a lot of redundant content and pushing out excessive detail to subarticles. There is still some rambling and excessive detail for an overview article to take care of, but length is no longer an emergency (so I removed that cleanup tag). The Applications section in particular could probably use a complete rewrite. Once this article and Database management system are cleaned up a bit more, I think it would be an improvement to merge them. The distinction between the logical data part and the surrounding system that makes it work in the real world is rather awkward, and we end up talking about both in both articles since they are so interrelated. The distinction can just be mentioned in a "Terminology" section. We need to be careful that the result of the merge is shorter than just the sum of the two articles, though, because otherwise it would be too long. But, we should be able to reduce a lot of redundancy by combining parallel sections on history, functionality, transactions, data models, and terminology. -- Beland (talk) 20:07, 5 March 2013 (UTC)

Congratulations, a big improvement. But much remains to be done. Perhaps as the article is now half the length and a much better baseline to work with, I'll have a bit of a go myself. Mhkay (talk) 11:26, 8 March 2013 (UTC)
I see you have indeed been compacting things; thanks for that! I gave a huge push of merging and making-concise today, and finally managed to merge the DBMS article here completely. The result is still a bit wordy and could certainly use a second look by other editors such as yourself. -- Beland (talk) 07:47, 16 March 2013 (UTC)

The ragbag Architecture/Aspects section

I attempted to split the unweildy section 6 into two parts, the first concerned with architectural principles of database technology, the second more concerned with development processes. It wasn't a perfect split, but I was hoping it could lead to a more structured approach. Someone has reverted the change and lumped it all together again, which makes it look like a ragbag with no structure at all; the lack of focus is evident in the difficulty of finding a title and introduction that says what the section is about.Mhkay (talk) 09:13, 16 March 2013 (UTC)

I agree this section could use some better organization or maybe get more concise. The subsections "Data independence" and "Database normalization" could probably be combined into the subsection "Database design" and the details moved into the subarticle Database design. The subsection "External, conceptual, and internal views" also duplicates a section of database design, and it's strongly related to data independence, so I might throw that in there as well. At the very least, the three "views" are not explained very well, and the graphic is not really helping. Probably a concrete example there would help a lot. -- Beland (talk) 05:20, 18 March 2013 (UTC)

Dubious

I moved the below here from Talk:Database management system because it is unresolved. I tagged the problem sentence in the article itself to point here. -- Beland (talk) 07:44, 16 March 2013 (UTC)

INGRES AS THE BASE OF MANY COMERCIAL DATABASE PRODUCTS -- Is it true?

The article includes this paragraph, which has no references associated with it.

"Many of the people involved with INGRES became convinced of the future commercial success of such systems, and formed their own companies to commercialize the work but with an SQL interface. Sybase, Informix, NonStop SQL and eventually Ingres itself were all being sold as offshoots to the original INGRES product in the 1980s. Even Microsoft SQL Server is actually a re-built version of Sybase, and thus, INGRES. Only Larry Ellison's Oracle started from a different chain, based on IBM's papers on System R, and beat IBM to market when the first version was released in 1978."

I have first hand knowledge of several of the products mentoined here and I do not believe they were based on INGRES, as is claimed.

I do know that SQL Server did begin as a version of Sybase, that is correct. I do not know that Sybase was a version of INGRES, as is claimed, but it may be.

It is my belief that Informix shares no heritage with INGRES, (IE: no common code) and was an organic outgrowth of Informix's early products, which were development languages. Of course people familiar with INGRES maybe have worked on it. (That is not the claim being made here, though.)

I am equally sceptical about the Non-Stop SQL Claim.

I'm going to do a little checking up, but I may delete or rewrite this paragraph. If someone is invested in keeping these claims here it would be helpful if they would source them.

24.22.76.36 (talk) 20:11, 21 September 2012 (UTC)

I agree, the claim is highly dubious. It's true that Berkeley Ingres was open source and therefore available to everyone, so one can't be sure what use anyone made of it. Of course all these products came from Silicon Valley and there was much interchange of staff and therefore of ideas, but I've seen no evidence that there was common code: except that I think Microsoft formally licensed the Sybase code. Of course Oracle itself aggressively recruited staff with experience in the other database companies, so on this measure it wasn't an independent venture either.Mhkay (talk) 09:13, 16 March 2013 (UTC)

Since everyone so far is pretty dubious, I'm moving the actual text here. If anyone wants to find some solid sources and/or rewrite it to be more accurate, feel free to put it back in the article. -- Beland (talk) 05:25, 18 March 2013 (UTC)

Many of the people involved with INGRES became convinced of the future commercial success of such systems, and formed their own companies to commercialize the work but with an SQL interface. Sybase, Informix, NonStop SQL and eventually Ingres itself were all being sold as offshoots to the original INGRES product in the 1980s. Even Microsoft SQL Server is actually a re-built version of Sybase, and thus, INGRES.

Microsoft Access

Perhaps there should be a mention of Microsoft Access following "1980s Desktop Databases" section. More readers are likely to have experience with Microsoft Access than dBASE and below its GUI Microsoft Access supports SQL. Then explain limitations of Microsoft Access (ie. number of simultaneous users) and introduce enterprise databases such as Microsoft SQL, Oracle and IBM DB2 and open source databases MySQL and PostgreSQL. Jim.Callahan,Orlando (talk) 23:47, 4 May 2013 (UTC)

Rows and Columns

Who on earth added that nonsense right at the start that all databases consist of rows and columns? I expect this was some ignorant school child inserting what they were told by an equally ignorant school teacher. This article seems to be a constant struggle against people who have never read a book or scholarly article about databases, but think they know it all. Sigh. Mhkay (talk) 13:13, 13 July 2013 (UTC)

"The data are" in the second sentence is incorrect.

It should be "The data is", not "are". — Preceding unsigned comment added by 169.139.19.174 (talk) 21:03, 17 December 2013 (UTC)

"Data" is the plural form of "datum". It's also often used as a collective noun like "people". In common usage "data" is often used as a singular noun but technically "data are" is correct, so I'd recommend leaving it as is. Jojalozzo 22:31, 17 December 2013 (UTC)

Codasyl vs. CODASYL

I changed all occurrences of the first to the second, per reference.[1]Peter Flass (talk) 13:22, 21 February 2014 (UTC)

References

  1. ^ Charles Babbage Institute. "Conference on Data Systems Languages Records, 1959-1987. Finding Aid". Retrieved Feb 20, 2014.

Information Principle redirects here, but is not mentioned

Either discuss it in the article or remove the redirect, so perhaps an actual page about it could be made? — Preceding unsigned comment added by 68.227.46.192 (talk) 13:24, 25 December 2013 (UTC)

Should it redirect here: Laws of information systems? Peter Flass (talk) 13:28, 21 February 2014 (UTC)

All SQL?

From the lede:

the most popular database systems since the 1980s have all supported the relational model as represented by the SQL language

I find that hard to believe given the NoSQL trend/hype of the last decade. CouchDB, MongoDB, Apache Cassandra, etc., all qualify as DBMSs as defined in this article, but don't support the relational model or SQL.

More generally, the lede seems rather slanted towards SQL. Does anyone have a reliable source that quantifies the popularity of SQL/NoSQL? On NoSQL, I found this web page that purports to show that at least in terms of number of major systems, RDBMSs are now in the minority. QVVERTYVS (hm?) 18:53, 23 June 2015 (UTC)

But, has an invividual NoSQL system actually made it into the ranks of "the most puplar databases systems"? —SamB (talk) 18:38, 3 July 2015 (UTC)
According to that very same website, yes. In its popularity ranking, Mongo currently ranks 4, Cassandra 8, Redis 10. Among the top 20 systems, at most 13 support SQL. QVVERTYVS (hm?) 18:54, 3 July 2015 (UTC)
The article you cite says nothing of the kind. It says that its figures "show that relational systems currently totally dominate the database market, but NoSQL systems have a strong upcoming trend" Its figures show 6 of the top 7 being relational, together accounting for about 95% of the market. Mhkay (talk) 22:21, 3 July 2015 (UTC)
Where's this 95% figure? I don't see it. QVVERTYVS (hm?) 11:02, 4 July 2015 (UTC)

(see Implementation section below)

(see Implementation section below) is repeated twice, but no section with this title can be found — Preceding unsigned comment added by Velocipedus (talk • contribs) 01:27, 26 November 2015 (UTC)

That section was removed 2½ years ago; it was a summary of the separate article Database management system that was merged into this article. I've removed the references as the treatment of DBMSs no longer has any separate section or article. QVVERTYVS (hm?) 12:22, 26 November 2015 (UTC)

databank

How is it possible that the word databank is not even mentioned in this article? The difference between the two or the lack of one is badly explained in that article. --Espoo (talk) 05:56, 4 August 2016 (UTC)

Hello fellow Wikipedians,

I have just modified one external link on Database. Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:

When you have finished reviewing my changes, you may follow the instructions on the template below to fix any issues with the URLs.

This message was posted before February 2018. After February 2018, "External links modified" talk page sections are no longer generated or monitored by InternetArchiveBot. No special action is required regarding these talk page notices, other than regular verification using the archive tool instructions below. Editors have permission to delete these "External links modified" talk page sections if they want to de-clutter talk pages, but see the RfC before doing mass systematic removals. This message is updated dynamically through the template {{source check}} (last update: 5 June 2024).

  • If you have discovered URLs which were erroneously considered dead by the bot, you can report them with this tool.
  • If you found an error with any archives or the URLs themselves, you can fix them with this tool.

Cheers.—InternetArchiveBot (Report bug) 02:30, 24 May 2017 (UTC)

Split Database management systems again

I am reasonably minded Database management systems (DBMS) should be split from this Database article to separate and clarify the concepts and to avoid undue weight. This would likely be a contraversial split. The predicate restricting this article to DBMS controlled databases is likely inappropriate, (although it is broken at one point) especially given its a level-4 vital article. Id' go even farther to say article with this name should have a broader and summarising view of the subject broadly covering the scope of the Outline of databases page. We should surely be asking is the article compatible with Microsoft Access, Apache derby, Embedded database or is it over-focusing on internals or databases like Oracle or DB2 to the omission of a user view of a database like say Wikispecies ? I currently calculate I don't have the bandwidth or energy to pursue this.Djm-leighpark (talk) 12:42, 21 August 2018 (UTC)

Retrieved from "https://wiki.riteme.site/w/index.php?title=Talk:Database/Archive_2&oldid=1030726777"