Call That a Database? This is a Database.

SQLServerCentral is supported by Red Gate Software Ltd.

Popular Topics

Home

Members

Calendar

Who's On

Home » SQLServerCentral.com » Editorials » Call That a Database? This is a Database.

18 posts, Page 1 of 2

1 2 »»

Call That a Database? This is a Database.

Rate Topic

Display Mode

Topic Options

Author

Message

Phil Factor

Posted Saturday, February 25, 2012 11:22 AM

Mr or Mrs. 500

Group: General Forum Members
Last Login: Sunday, May 19, 2013 4:00 AM
Points: 533, Visits: 2,285

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

Best wishes,

Phil Factor
Simple Talk

Post #1257817

sengeet86

Posted Saturday, February 25, 2012 11:30 AM

Valued Member

Group: General Forum Members
Last Login: Sunday, September 23, 2012 8:02 AM
Points: 58, Visits: 67

Nice Article. Smile

java programming

Post #1257819

Jeff Moden

Posted Saturday, February 25, 2012 11:37 AM

SSC-Dedicated

Group: General Forum Members
Last Login: Yesterday @ 4:51 PM
Points: 32,923, Visits: 26,811

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."

For better, quicker answers on T-SQL questions, click on the following...
http://www.sqlservercentral.com/articles/Best+Practices/61537/

For better answers on performance questions, click on the following...
http://www.sqlservercentral.com/articles/SQLServerCentral/66909/

Post #1257820

pdanes

Posted Saturday, February 25, 2012 1:06 PM

SSC Veteran

Group: General Forum Members
Last Login: Monday, May 20, 2013 4:36 AM
Points: 257, Visits: 690

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?

Post #1257858

andrew.ing

Posted Sunday, February 26, 2012 9:49 AM

SSC Journeyman

Group: General Forum Members
Last Login: Monday, May 20, 2013 2:00 AM
Points: 93, Visits: 338

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.

Post #1257950

richardicus

Posted Sunday, February 26, 2012 5:03 PM

Forum Newbie

Group: General Forum Members
Last Login: Friday, March 22, 2013 8:33 AM
Points: 2, Visits: 94

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.

Post #1257980

P Jones

Posted Monday, February 27, 2012 2:00 AM

Mr or Mrs. 500

Group: General Forum Members
Last Login: Monday, May 20, 2013 7:35 AM
Points: 515, Visits: 1,016

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!

Post #1258071

simonball

Posted Monday, February 27, 2012 2:43 AM

Forum Newbie

Group: General Forum Members
Last Login: Wednesday, April 24, 2013 8:41 AM
Points: 2, Visits: 35

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...

me:"Emily! We do not pull the wallpaper off the walls!"
Emily (aged 3)<sulkily mumbles>:"We do because we can."

Post #1258087

Lucy Dickinson

Posted Monday, February 27, 2012 5:05 AM

Valued Member

Group: General Forum Members
Last Login: Yesterday @ 9:01 AM
Points: 71, Visits: 81

Wonderfully descriptive, love this .. particularly Abcess BigGrin

Lucy Dickinson
BI SQL Developer

Post #1258151

pbowman-543344

Posted Monday, February 27, 2012 6:01 AM

Grasshopper

Group: General Forum Members
Last Login: Thursday, April 25, 2013 2:38 AM
Points: 20, Visits: 124

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.

Post #1258180

« Prev Topic | Next Topic »

18 posts, Page 1 of 2

1 2 »»

Permissions