September 26, 2015 at 11:20 pm
Comments posted to this topic are about the item A Case for Database CI
Best wishes,
Phil Factor
September 27, 2015 at 6:51 am
Time after time I have been called only when problems bubbled up to management who made the decision to call-in an experienced person to diagnose "the database problem".
The problem's cause, without fail, is the design. People who cope with it don't know that and the contractors who designed it prefer not to get blamed. None of that matters. I once advised a contracting company on precisely what was wrong with their design and they did it anyway! If you do many builds and they are predicated on the same flawed design, multiple builds won't matter.
A variation on an old saying seems appropriate. Don't teach a pig. He won't understand it and you'll annoy the pig. People don't like to think ahead, don't like to plan, don't like to anticipate problems in design.
Executives think buying lots of hardware prevents problems. They think getting the software developed quickly will save money. Neither of these is true. Design correctly for the planned number of users in 5 years, design for security when the company goes public, design so it is easily extended. This is how executives should think. They invariably don't. They end up spending more money and getting an inferior software product.
So the problem lies with how money is allocated to produce production databases. Until that problem is solved (thankfully, it will likely never be solved), developers and contractors will continue designing databases and data processing using the same failing methodology and experienced people will be called-in when the pain is so great the business has stark choices.
Those facts have been making me a living for the better part of 20 years. Thanks to all the executives for being so predictably dumb in your approaches to software and database development and design. My only regret lies with the developers who never learn how to create optimal database designs and data processing.
Multiple builds are OK. A good design beats multiple builds hands down every time.
September 27, 2015 at 10:52 am
Absolutely right. The problem is inevitably in the design. If developers designed their databases properly, we'd be out of a living. Developers give their problems fancy names but it all boils down to really bad database design that, if they did the same thing in C# or Java, they'd be hissed at roundly by their peers and mentors.
Best wishes,
Phil Factor
September 27, 2015 at 11:14 am
Sometimes management and development don't have the imagination or foresight to anticipate problems that may occur later in a database applications lifetime when the tables have grown too large for simplistic solutions. As a consultant, DBA or product support tech you end up caught between management and the users of the application whose design is causing serious issues months or years later.
September 27, 2015 at 6:37 pm
Sad but true. In my decades as an independent I have twice walked away from database implementations pushed by a company's accounting firm that I tried to convince both the company and the accounting firm's "consultants" that their DB solution would end up costing too much over a solution I recommended while still not providing the needed transaction rate/concurrency with the hardware being recommended. I left with a clear conscience, the accounting firms in both cases raked in the dough 🙁
September 28, 2015 at 7:51 am
True powerlessness is being brought into such a mess only to find out that you are damned if you do and damned if you don't. I was once brought into a project where the team had spent over a year accomplishing absolutely nothing. Everything revolved around an ORM pushed by developers with a very weak grasp on ORMs. Long story short, they wouldn't (or couldn't) program objects, so they jumped through hoops for their tools, and then when those tools did something contrary they were beyond lost. They weren't interested in solutions; they wanted to keep doing what they had been doing and magically receive different results. Unfortunately for contractors, it's too easy to spin the situation as "X was brought on board but we are no better off so therefore X is not helping."
September 28, 2015 at 9:25 am
Thanks for the laugh! Smile, fix it and moved on. I'd like to be the thinker, but alas I'm a doer. On the bright side, tremendous job security.
September 29, 2015 at 12:39 am
I do find watching slow motion train crashes a bit sad at the moment. Currently watching yet another project that is ORM based. I asked how they were going to do the reports the reply was "..its not a problem we use MVC and CSS so we can do any report. It will only take a couple of days for each report." To these guys DevOps mean no-ops and they have already regressed indexes back so many times it has become predictable fortnightly event when they release code. Never mind at least its on the MySQL database outside of my remit.
Of course they are talking about CI & CD. Yep, its a another silver bullet that will help.
September 29, 2015 at 3:12 pm
I've found that some advice is better received when delivered one-on-one rather than in front of a group. Otherwise, the ignorance of the crowd or the cult personality of the local perceived expert will beat it down. You have to identify the person who is most receptive and in a position to be influential and then work on them. Sometimes email works best, because it gives you the opportunity to complete your point uninterrupted, and each team member can read and reflect upon it privately.
"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho
September 29, 2015 at 4:06 pm
dg81328 (9/27/2015)
Time after time I have been called only when problems bubbled up to management who made the decision to call-in an experienced person to diagnose "the database problem".The problem's cause, without fail, is the design. People who cope with it don't know that and the contractors who designed it prefer not to get blamed. None of that matters. I once advised a contracting company on precisely what was wrong with their design and they did it anyway! If you do many builds and they are predicated on the same flawed design, multiple builds won't matter.
A variation on an old saying seems appropriate. Don't teach a pig. He won't understand it and you'll annoy the pig. People don't like to think ahead, don't like to plan, don't like to anticipate problems in design.
Executives think buying lots of hardware prevents problems. They think getting the software developed quickly will save money. Neither of these is true. Design correctly for the planned number of users in 5 years, design for security when the company goes public, design so it is easily extended. This is how executives should think. They invariably don't. They end up spending more money and getting an inferior software product.
So the problem lies with how money is allocated to produce production databases. Until that problem is solved (thankfully, it will likely never be solved), developers and contractors will continue designing databases and data processing using the same failing methodology and experienced people will be called-in when the pain is so great the business has stark choices.
Those facts have been making me a living for the better part of 20 years. Thanks to all the executives for being so predictably dumb in your approaches to software and database development and design. My only regret lies with the developers who never learn how to create optimal database designs and data processing.
Multiple builds are OK. A good design beats multiple builds hands down every time.
Spot on! And to counter the "Case for Database CI", humans can certainly make a mess of things but to promote such mistakes much more quickly, use a computer to automatically deploy for CI. 😀
--Jeff Moden
Change is inevitable... Change for the better is not.
September 30, 2015 at 7:17 pm
Yet Another DBA (9/29/2015)
I do find watching slow motion train crashes a bit sad at the moment. Currently watching yet another project that is ORM based. I asked how they were going to do the reports the reply was "..its not a problem we use MVC and CSS so we can do any report. It will only take a couple of days for each report."
I can't agree more, too often devs see (or are preached to) MVC and CSS as all that is needed. I too have yet to see a decent ORM implementation ... GUIDs all over the place ... but using a GUID as a primary clustered key? ... for every table? ... and then the question comes back shortly after real world implementation "why is the database so slow". Once again "it works here" but not in real life. ORMs are sold to corporations to "make the developer's life easier", but there is no mention of how the database will perform, that is apparently the responsibility of the developers. Those who use only an ORM have never had the real world under the hood experience of real database design with real performance.
November 16, 2015 at 6:24 am
I am with you DBAs with your skepticism of ORMs, however, CI & CD, whilst no silver bullet, encourages early updates which also encourages a reasonable process for updating to be in place both for database schema management as well as data management.
A better team will also set up some performance testing early on too. Of course these are likely to only be indicative results but can highlight design issues early.
I would like to point out that no tool nor technique can better education. I don't necessarily mean from an academic institution (possibly I mean NOT from an academic institution ) but just the appropriate amount of knowledge AND understanding. In this case knowledge and understanding of relational theory and its application is a must e.g. if someone developing a database schema does not know about 3NF (just an example) or cannot explain it then they are not adequately equipped to perform their duties.
Gaz
-- Stop your grinnin' and drop your linen...they're everywhere!!!
Viewing 12 posts - 1 through 11 (of 11 total)
You must be logged in to reply to this topic. Login to reply