Bag Versus Set Controversy Roadmap

This is an attempt to catalog the various topics and pages about the long and divisive relational "bags versus sets" debate.

• BagAtational
• BagAtationalDiscussion
• BagSetImpedanceMismatch
• BagSetImpedanceMismatchDiscussion - How to handle incoming non-keyed data
• BagNeedScenarios - 5 scenarios allegedly influenced by actual situations
• BagNeedScenariosReWork - An in-progress attempt to reorganize BagNeedScenarios
• ComplexityOfOutputtingDuplicateTuplesInTutorialDee
• NewQueryLanguagesOnExistingEngines
• HowOtherQueryLanguagesAddressSqlFlaws
• BaglessSql
• RelExportDiscussion
• TrueRelationalToPseudoRelationalImpedanceMismatch

Indirectly Related

• OrderedBag
• AlwaysUseSelectDistinct
• SelectDistinctIsaCodeSmell
• TupleOrientedProgramming
• AutoKeysVersusDomainKeys
• AutoKeysVersusDomainKeysDiscussion
• TutorialDee
• SmeQl
• RecordBasedDatabase

Recent or Active Debates and New Topics:

• BagSetImpedanceMismatchDiscussion (Feb. 2012)
• NewQueryLanguagesOnExistingEngines (Jan. 2012)

---

Note that positions on this issue can be classified into one of three:

• Bags are always to be avoided
• Sets should be the default, but bags allowed via an extra key-word or specifiers
• Bags are the default (Most existing SQL-based RDBMS are configured this way.)

I generally fall into the middle camp because compatibility with existing (bag) systems is important. If we could flush the IT world and start over, I'd consider the first stance some more. --top

---

CategoryIdentity