Table Weenie

Distinctions:

Overlaps: This page is The topic name "weenie" is a tradition here. Economics is not less "academic" than math. Although one could argue that one is a "hard" topic and the other "soft" in that it approaches having TooManyVariablesForScience. But being a "soft" science/subject does not necessarily make it any less valid. It's a case SovietShoeFactoryPrinciple at play. Related DisciplineEnvy.

Some people claim to be a RelationalWeenie, but they are actually a TableWeenie.

A table wheenie doesn't care about relational purity or tuple purity, he cares more about a table oriented product that just works whether pure or not. A table wheenie can be satisfied with bags or tuples, or both, and can be satisfied with rows and tables rather than more pure relvars and tuples.

"Doesn't care" may be an excessive characterization. "Allow but discourage" would be my point of view. Tools should allow bags, but gently discourage them, for example (SQL doesn't currently qualify, BTW). And relational with bags is not different enough from relational without bags to make an entire distinction. I consider them different sects of relational rather than a different religion. The operations, concepts, and idioms are very similar under each. (Somewhere there are a couple of long heated topics that debate this.) -t

{By definition, the RelationalModel does not allow duplicate tuples. "Relational with bags" is not the RelationalModel.}

It's my opinion that some overly-obsess on "the uniqueness thing". The real world is often messy, and bags sometimes better match that fact, and/or can save resources. But, there are approximately a dozen existing topics that debate this issue such that I won't reinvent it further here. See BagVersusSetControversyRoadmap for more on that. -t

{Be that as it may, the RelationalModel does not allow duplicate tuples. So, by definition, not enforcing "the uniqueness thing" means you're not using the RelationalModel, and that makes you -- as is suggested above -- a TableWeenie rather than a RelationalWeenie.}

Most RDBMS are then not "true relational" either, but merely "relational influenced" by that standard. I see no reason to get caught up in NoTrueScotsman-like fights. They are tools, with various trade-offs involved. I generally don't put high gravity on that trait because it makes only a minor difference to how the tool would be USED in practice, which is the more important aspect of a tool. Oracle, IBM, Microsoft, and Sybase decided not to go the "pure" route. If you wish to spank these companies, go ahead; I won't stop you. In fact, I encourage you to. Just bring some nice reading material for your cell stay. Just give me a heads-up warning so that I can buy a box of high-quality tissues because I will be laughing my caboose off when I see the headline in the papers: 

  RELATIONAL PURIST GOES NUTS AT IBM HEADQUARTERS
  A man was arrested today for forcing himself past
  security and yelling at IBM's CEO, Ginni Rometty,
  for "allowing bags" in IBM's database products.
  Mrs. Rometty was quoted as saying, "I'm not quite
  sure what he was yelling about, but I'm glad we
  do allow bags; we need them to wrap up nuts 
  like him and carry them to the loony bin."
{What does that have to do with what I wrote?}

Please clarify. My point is that the distinction between "relational" and "bagatational" is relatively minor.

{The distinction between some loose use of "relational" and "bagatational" may be whatever you want them to be. Neither are recognised terminology. The difference between the RelationalModel and SQL DBMSs, however, is significant. My point, and the point of this page, have nothing to do with specific products -- except being a fan of SQL is further evidence of being a TableWeenie and not a RelationalWeenie. My point, and this page, are about the difference between proponents of "tables" in general vs proponents of the RelationalModel in particular.}

Sorry, but I don't see them as huge distinctions. And I am not a "fan of SQL". I wouldn't have drafted SmeQl if I were. But, until something gains enough market share and is significantly better, I see no reason to displace SQL. And SQL can be "de-bagged" without throwing the baby out with the bath-water such that "SQL or uniqueness" is a false dichotomy if we consider possible dialects of SQL. Bag-ness and SQL-ness are generally orthogonal, as are many features of typical DB's and DB engines. (As far as the terminology, you are welcome to suggest a better term for such "non-pure" RDBMS.)

{Again, according to this page, that makes you a TableWeenie, not a RelationalWeenie.}

You probably put that distinction near the top. I'd vote against it being placed there, given a choice.

{Yes, and that makes you a TableWeenie, not a RelationalWeenie. If you voted that the distinction should be there, along with other aspects of adhering to the RelationalModel, you'd be a RelationalWeenie and not a TableWeenie.}

You seem to want to shoe-horn multiple aspects into Boolean slots. There are various aspects/features of tables and relational, and rejecting some doesn't necessarily mean one rejects all. The granularity of "relational" OR "tables" is too course to be useful or informative. Perhaps we can draft up a list:

{Only "unique rows forced/required" has anything to do with the RelationalModel. The rest are orthogonal to the RelationalModel. If "unique rows forced/required" isn't present, it isn't the RelationalModel. If you're not in favour of "unique rows forced/required", then by definition you're not a proponent of the RelationalModel. That makes you not a RelationalWeenie.}

Are you saying the ONLY difference between "table" and "relational" is the unique row requirement? If so, why not call those with such a preference Unique Row Weenies?

Some define "relational" by Codd's 12 Rules: http://en.wikipedia.org/wiki/Codd%27s_12_rules

See also: TableOrientedProgramming, TopMind

CategoryDiscussion CategoryDataOrientation

EditText of this page (last edited December 3, 2014) or FindPage with title or text search