Call That a Database? This is a Database.

  • Comments posted to this topic are about the item Call That a Database? This is a Database.

    Best wishes,
    Phil Factor

  • Nice Article. 🙂

  • BWAA-HAAA!!!! In that vein, I have a simple name for most databases I've seen in my life whether they be small or large. "Snowman Databases". They look really cool (sorry, no pun intended) in the "front yard" where all the managers can see them, they take exponentially longer to build and more resources the bigger they are, and they simple melt and fall apart at the first sign of any real heat. Perhaps "Puddle Database" would be an even more appropriate name.

    --Jeff Moden


    RBAR is pronounced "ree-bar" and is a "Modenism" for Row-By-Agonizing-Row.
    First step towards the paradigm shift of writing Set Based code:
    ________Stop thinking about what you want to do to a ROW... think, instead, of what you want to do to a COLUMN.

    Change is inevitable... Change for the better is not.


    Helpful Links:
    How to post code problems
    How to Post Performance Problems
    Create a Tally Function (fnTally)

  • Interesting idea. What all parameters of these constructs should be part of the descriptive vocabulary? Size, speed, complexity, efficiency, stability, level of automation, time in service, scalability, maintainability, hardware environment, standardization, modularity, flexibility...? The mind boggles at the multitude of possible forms a database can take. A vocabulary that would describe all such combinations of parameters would be quite large. I, for one, have enough difficulty remembering all the terminology we currently use. Learning hundreds, maybe thousands of new words just to be able to refer to every obscure combination of properties that someone has managed to assemble with a single word is not time I would care to invest.

    I do like tiddlybase, though. Maybe ittybase, for the home recipe or telephone number file?

  • I wonder if Eskimo actually does have 60 words for snow (or any number large enough to be noteworthy).

    The linguist Geoff Pullum (whose article style I have always been reminded of by Phil Factor's) looked at how these probably inflated word counts arose in his amusing and readable short essay The Great Eskimo Vocabulary Hoax.

    He locates an early 20C writer who, musing on specialised vocabularies, suggests that Eskimo might have a number of terms for snow. The writer only mentioned four examples, but the idea was attractive, and any subsequent commentator seemed compelled to improve the point when quoting it. Pullum sees the number of words rising over the years to "one hundred" (New York Times, 1984) and "two hundred" (a weather forecast in same year;). I expect we've all heard various numbers since then.

    Disappointingly, there might only be two Eskimo terms for snow - that's all Pullum can find in the Dictionary of West Greenlandic Eskimo Language (1927). These root terms will turn up in multiple forms of course - just as English word snow crops up in snowball, snowdrift, snowflake, etc; but if you count these forms then English will also have a large number.

    Anyway, that's enough sidetracking of the discussion: all this is in the article if you're interested (http://users.utu.fi/freder/Pullum-Eskimo-VocabHoax.pdf) . In the end neither the answer nor the question, "how many words does Eskimo have for snow?", turns out to be straightforward.

  • How about using SI prefixes with tuple? So a megatuple is a datastore with about a million rows.

    We also need a term for the repository that you have been asked to sort out because it's becoming 'sort-of mission critical' which when you inspect turns out to be a uber-huge web of interconnected spreadsheets..... preferably one that doesn't include profanities.

  • Great article - I love our language!

    Can anyone suggest a suitable word for the all-import-no-design reporting database that's made up from flat file extracts from business OLTP systems imported daily with ssis, is simple recovery, read-only to users who run ssis reports, yet is 60Gb of data and growing daily plus a transaction log on a meaty, multi-processor server and is regarded as business critical! Queries then run slowly and spawn new tables and indexes to fix the problem thus evolving the database.

    I can only think of megamix, dumpbase or Darwinbase!

  • Excellent article. I'd like to contribute some possible names

    i like Microbase for tiny home office type "cd collection" db's, ( inferring that its a well normalised decent DB, just very small)

    and MegaBase for large scale institution pervasive decent structure DB.. and its evil cousin, the large important badly normalised high table count behemoths as a behemobase. ( i'd apply Behemobase to P jones example)

    also, i have encountered lots of spreadsheets which are nicely formatted as proper dataset, but then under the hood they are riddled with countless Vlookups and no validation ( and even horror of horros - Hlookups....).... i'd call those a Spreadbase, because they spread like wild fire.

    Those lists people provide you in excel, where they have used colour and font and italics / bold to denote important aspects or status of their records..which an import to SQL or Access won't pick up need a name as well....failbase?

    Although i am partial to a bit of Access and Excel VBA, one of my old colleagues used to refer to my efforts alternately as Abcess and Excess databases...

    [font="Courier New"]me:"Emily! We do not pull the wallpaper off the walls!"
    Emily (aged 3)<sulkily mumbles>:"We do because we can."[/font]
  • Wonderfully descriptive, love this .. particularly Abcess 😀

    Lucy Dickinson
    BI SQL Developer

  • diddybase - < 1Gb, especially the "test" or "proof of concept" databases, beloved of developers, with less than 10,000 records in each table, or with an entire dataset < available RAM.

    terrorbase - Terabytes. Lots of em.

    But I agree with Phil, the biggest lack is words for proper OLTP systems with hundreds/thousands of simultaneous processes needing to do non-repudiable, acid-compliant transactions without deadlocking. Think stock exchanges or other trading platforms.

  • pbowman-543344 (2/27/2012)


    diddybase - < 1Gb, especially the "test" or "proof of concept" databases, beloved of developers, with less than 10,000 records in each table, or with an entire dataset < available RAM.

    terrorbase - Terabytes. Lots of em.

    But I agree with Phil, the biggest lack is words for proper OLTP systems with hundreds/thousands of simultaneous processes needing to do non-repudiable, acid-compliant transactions without deadlocking. Think stock exchanges or other trading platforms.

    Love Diddybase!

    suggestion for an Online transactransaction mega massive database?

    an Oltrabase? or an Oltra Mega-base

    [font="Courier New"]me:"Emily! We do not pull the wallpaper off the walls!"
    Emily (aged 3)<sulkily mumbles>:"We do because we can."[/font]
  • Great one, Phil, and we certainly need better terms. This large/very large, isn't a good choice as that will constantly evolve. Made up words that describe size, scale, or even rate of transactions, would be better.

    Provided that we don't try to be marketers and create words that imply we've ever reached some limit, like the Ultimabase or something similar.

  • Great topic. I think there's a perfect metaphor around highway interchanges. I particularly like this description of so-called stack interchanges: "This is not only expensive but also creates an eyesore among local residents, leading to considerable NIMBY (Not In My Back Yard) opposition. Large stacks with multiple levels are often colloquially described as Mixmasters or spaghetti bowls due to their complex appearance, being compared to boiled spaghetti." So perhaps something like this works:

    CASE

    WHEN DatabaseSize > 1Tb and Concurrency > 1000

    THEN 'CloverStack'

    WHEN DatabaseSize BETWEEN 100Gb AND 1Tb and Concurrency > 500

    THEN 'CloverLeaf'

    WHEN DatabaseSize BETWEEN 1Gb AND 100Gb and Concurrency > 50

    THEN 'Roundabout'

    WHEN DatabaseSize BETWEEN 1Mb AND 1Gb and Concurrency < 20

    THEN 'Mayberry'

    END as DatabaseClass

    I'm sure there are holes in my CASE statement, but there are tons of possibilities. And when you think about it we're trying to keep everything flowing as best we can with unpredictable inputs (volume of traffic, size of vehicles, weather conditions, etc.), a limited budget and specs that change after the infrastructure has been hardened.

    Great topic.

    ~~ Everything in moderation, including moderation. ~~

  • I've just used the term 'unCoddly' for a database that had all sorts of de-normalisations in it.

    As regarding having to remember the types of database, we all find it easy to remember the sixty names of types of dog. It is just as well, considering that there is a huge difference between a Chihuahua and a Great Dane.

    Best wishes,
    Phil Factor

  • Here's my two cents, FWIW: The fault for the effects of poor communication does not fall on the English language for it's lack of overly specific terminology. The fault lies with every one of us, who uses terms like "database" ambiguously. If you *mean* something like MS-Access running on a local workstation, say so. If you *mean* something like a mega/giga/tera-OLTP, say so. We have the words... use them.

    This has always been one of my pet peaves.... Too often, the speaker/writer has a fully formed specific idea of what he is talking about and in his own mind he knows what he, himself, specifically means by a word like "database" - - - but he fails to take into account the the context of the listener/reader with whom he is endeavoring to communicate. I always try to be concsious of ambiguities in certain terminology, and to explicitly resolve the specifics in my communication wherever warranted.

    Most miscommunication that I see happening comes BOTH from speakers *and* listeners failing to notice (even fairly obvious) abiguities in their words.

    For example, if there is *ANY* chance that the listener/reader might interpret my use of the word "database" as something like MS-Access, when I really mean something like SQL Server, .... *and* if that difference is germane to the discussion, I'll try to be very explicit in what I am talking about and why it is a relevant distinction.

    I don't think we need to invent new words for this. In fact, I think it might actually be counter-productive because there are SO many combinations and permutations of database features, scopes, scales, etc... that we'd end up with such a proliferation of new words, they would only confuse things further.

Viewing 15 posts - 1 through 15 (of 17 total)

You must be logged in to reply to this topic. Login to reply