March 7, 2015 at 4:21 am
Comments posted to this topic are about the item Fifty Words for Databases
Best wishes,
Phil Factor
March 7, 2015 at 4:35 pm
Hey, I've cataloged my CD *and* book collection in a database, so I'm ahead of that guy...
The D-word alone is rather generic. I work with people who call their spreadsheet a database. Even on the SQL Server side, we have databases whose primary table of business data may never exceed 50k rows.
March 7, 2015 at 8:03 pm
What??? You don't know how to get to the moon, Phil???? It's simple! All you have to do is build a rocket ship! 😛
Absolutely great editorial, ol' friend. It should be required reading for all IT managers, Project Managers, other people in the business of writing requirements and estimating time-to-completion, and those folks who don't think they need to get a good Database Developer or DBA involved. I especially like one of the sentences in the leading paragraph.
Reality always comes as a shock, because the closer you get to any real task, the more you come to appreciate the skills that are necessary to accomplish it.
Unfortunately, a lot of people never realize the shock because they never get close to reality. 🙂
--Jeff Moden
Change is inevitable... Change for the better is not.
March 9, 2015 at 1:34 am
To be fair, this kind of simplification occurs with all technologies. For those of you who feel the need to be patronised, just consider the programming demos where a drag here and a click there produces a working program which we then get told is shippable quality. Pah!!!
Gaz
-- Stop your grinnin' and drop your linen...they're everywhere!!!
March 9, 2015 at 3:29 am
@gary Varga
I think there is more of a problem here. Last year, I sat in a day seminar on Continuous Integration given by a director of a well-known consultancy who told an audience of forty or so people that in his view Oracle DBAs seemed more intent in working for Oracle rather than the companies who paid their salaries. This sort of poisonous nonsense is far more than merely patronizing. It is this sort of thinking that strikes me as being like a baby banging the spoon and screaming when dinner is late. I think that it is better for us to take positive action to make clear about the shed-load of work that is needed to turn a development into a production system.
Best wishes,
Phil Factor
March 9, 2015 at 3:47 am
Phil Factor (3/9/2015)
@Gary VargaI think there is more of a problem here. Last year, I sat in a day seminar on Continuous Integration given by a director of a well-known consultancy who told an audience of forty or so people that in his view Oracle DBAs seemed more intent in working for Oracle rather than the companies who paid their salaries. This sort of poisonous nonsense is far more than merely patronizing. It is this sort of thinking that strikes me as being like a baby banging the spoon and screaming when dinner is late. I think that it is better for us to take positive action to make clear about the shed-load of work that is needed to turn a development into a production system.
That Director was being disingenuous at best. The patronising I was referring to was me explaining another example of ridiculous, and possibly dangerous, presentations. When these presentations are taken on face value the naive follow it blindly and the selectively naive use it as a weapon.
My point was only that it is not limited to databases but all technologies. Sometimes it is too akin to TV Sales channels.
PS I know a lot of people here do great presentations and I am not tarring the whole format with the same brush. I think that the issue is with SOME presentations. Others are excellent.
Gaz
-- Stop your grinnin' and drop your linen...they're everywhere!!!
March 9, 2015 at 5:57 am
Phil Factor (3/9/2015)
@Gary VargaI think there is more of a problem here. Last year, I sat in a day seminar on Continuous Integration given by a director of a well-known consultancy who told an audience of forty or so people that in his view Oracle DBAs seemed more intent in working for Oracle rather than the companies who paid their salaries. This sort of poisonous nonsense is far more than merely patronizing. It is this sort of thinking that strikes me as being like a baby banging the spoon and screaming when dinner is late. I think that it is better for us to take positive action to make clear about the shed-load of work that is needed to turn a development into a production system.
No doubt this sort of thing contributes to the perennial DBA-vs-Developer divide. A supposed "expert" says how easy it is to go from dev to production then the DBA back home says, "Whoa, wait a minute, the situation is much more complicated than that."
I second Gary's point that it goes far beyond database technology. In my particular position I wear a lot of hats and lately our staff have become enamored with wireless technology. There are other business units who have networks with highly integrated wireless capabilities and staff around here keep asking for similar capabilities for us. I have to keep explaining over and over that at present we do not have a secure wireless infrastructure and until such exists, it isn't going to happen. We don't own the network and there are quite a few contractual and technical challenges to overcome to do it properly.
____________
Just my $0.02 from over here in the cheap seats of the peanut gallery - please adjust for inflation and/or your local currency.
March 9, 2015 at 6:46 am
Nice article. Unconsciously or unknowingly I have categorized our databases into six categories - a 2X3 array. One axis is disaster / recovery axis with two high level options; 'S' for simple backups and exports and 'R' for replication, standby servers, and more complex disaster recovery options. The other axis is the activity; simple transactional activity, short burst activity, and long burst activity (burst being some intense process hitting the database). The location of the database in the matrix impacts the disk space, additional hardware, RAM, log buffers, shared pool size, indexes, purging, and on and on. As the article indicates one size does not fit all. Sometimes people like to fit all databases into a size value. That parameter doesn't say much to me.
Tom A
March 9, 2015 at 7:33 am
I'm convinced that no more than 1 in 4 IT shops, and this includes everything from two man startups to major corporations, really just don't "get" database engineering. If you've gone through the process of interviewing for a job lately, then you know what I'm talking about.
Even in those cases where they ultimately call in a solid database consultant after the fact, what they end up doing is adding a layer of security and performance optimization on top of a poorly designed database that's already in production when options for meaningful change are limited. That's sort of like a chef sprinking spice on top of a fish that's been left to rot in the refridgerator for a week.
Normalization, data constraints, security, and performance have to be baked into the database from the beginning. But most development teams don't get that. They know how to design objects and HTML, but not tables, indexes, and SQL.
"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho
March 9, 2015 at 7:57 am
Eric M Russell (3/9/2015)
...Normalization, data constraints, security, and performance have to be baked into the database from the beginning. But most development teams don't get that. They know how to design objects and HTML, but not tables, indexes, and SQL.
The Internet boom has a lot to answer for. On the positive side some of the agile techniques that came from it are excellent (often recasting of existing teqniques) but on the negative side anything that encourages any kind of engineering rigour now often gets sniggered at.
Gaz
-- Stop your grinnin' and drop your linen...they're everywhere!!!
March 9, 2015 at 8:07 am
tom.artz (3/9/2015)
Nice article. Unconsciously or unknowingly I have categorized our databases into six categories - a 2X3 array. One axis is disaster / recovery axis with two high level options; 'S' for simple backups and exports and 'R' for replication, standby servers, and more complex disaster recovery options. The other axis is the activity; simple transactional activity, short burst activity, and long burst activity (burst being some intense process hitting the database). The location of the database in the matrix impacts the disk space, additional hardware, RAM, log buffers, shared pool size, indexes, purging, and on and on. As the article indicates one size does not fit all. Sometimes people like to fit all databases into a size value. That parameter doesn't say much to me.Tom A
I would add to Toms list the "class" of data being stored. My definition of class, in an academic environment in this case, would be Public, Directory, Non-Public, and Private.
Public - aggregate data( number of students enrolled in a particular class, how many are graduating, how many new entering freshman, etc.).
Directory - Name, email address, etc.
Non-Public - Grades, GPA's, gender, ethnicity, etc.
Private - SSN, credit card info, immunizations, medical info, student pay-roll, academic standing, etc.
The class of the data will determine which one of the 7 sql servers, in production, the database will be put on.
Bill Soranno
MCP, MCTS, MCITP DBA
Database Administrator
Winona State University
Maxwell 143
"Quality, like Success, is a Journey, not a Destination" - William Soranno '92
March 9, 2015 at 8:40 am
I've worked for organisations that used these simple categories to define the backup regimes, security, availability, location etc. ...
Private: - merely for the productivity of a single person or team
Departmental: - for the admistration of a department
Corporate: - Essential for the organisation to trade
Personal: - Requiring conformance with all legislation on holding personal information
Financial: - Requiring the full rigors of accounting and audit.
If an application fitted more than one category, it got the more severe requirements
.. nowadays, this is rather more nuanced in order to fit in with more recent legislation. I rather like the finer gradings of William Soranno's grading of personal information
I suspect that this sort of simple categorization leads directly into tom.artz's matrix for implementation architecture
Best wishes,
Phil Factor
March 9, 2015 at 8:47 am
In recent versions of SQL Server, we now have a handful of table types to choose from: traditional row store, Heckaton in-memory (high volume OLTP), ColumnStore (data warehousing). Each table type is optimized for a specific case usage, so it's important to classify how the table will be used in the bigger scheme of things before creating DDL for it.
"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho
March 9, 2015 at 8:50 am
tom.artz (3/9/2015)
Nice article. Unconsciously or unknowingly I have categorized our databases into six categories - a 2X3 array. One axis is disaster / recovery axis with two high level options; 'S' for simple backups and exports and 'R' for replication, standby servers, and more complex disaster recovery options. The other axis is the activity; simple transactional activity, short burst activity, and long burst activity (burst being some intense process hitting the database). The location of the database in the matrix impacts the disk space, additional hardware, RAM, log buffers, shared pool size, indexes, purging, and on and on. As the article indicates one size does not fit all. Sometimes people like to fit all databases into a size value. That parameter doesn't say much to me.Tom A
I think that's a pretty good starting point, Tom. People would need to customize it for their particular environment, but I really like the idea. The problem would be that people like to complicate things as a part of human (and/or DBA?) nature, so we'd probably start seeing 10x10 matrices.
Most of the databases that I've worked with/on would probably fit nicely in the top left corner, except for backups. I'm pretty rabid about backups for all databases including system DBs.
-----
[font="Arial"]Knowledge is of two kinds. We know a subject ourselves or we know where we can find information upon it. --Samuel Johnson[/font]
March 9, 2015 at 9:07 am
Any suggestions for suitable descriptive words for types of database?
'Web service'.
Abstracting out the database layer from the application offers a number of advantages -- not the least of which is not having to deal with cranky DBAs.
😉
Viewing 15 posts - 1 through 15 (of 23 total)
You must be logged in to reply to this topic. Login to reply