The Design Investment

Question

The Design Investment

Viewing 15 posts - 16 through 30 (of 63 total)

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

Stephen Hirsch SSCommitted Points: 1822 More actions · Answer 1

How did "designing databases" get separated from "development" in the first place? DDL is as much "code" as C#, Java, T-SQL, whatever.

<rant>

Please, please, please people, please stop using abbreviations! Please stop removing vowels! There used to be a reason to do that, but there isn't anymore. Physical names should be the same as logical names, at least 99% of the time. A reasonably intelligent native speaker should be able to read the physical names and understand what it's supposed to be/do.

</rant>

David Data SSCrazy Points: 2965 More actions · Answer 2

Round about 1980, I set a design standard for my department, which started with

DNT ABRV8

salman.samad Right there with Babe Points: 799 More actions · Answer 3

David Data (9/29/2010)
Round about 1980, I set a design standard for my department, which started with
DNT ABRV8

Laugh Out Loud!

Nadrek SSC-Insane Points: 20039 More actions · Answer 4

I would note that even for developers with a Computer Science degree, while relational theory may be covered (often optionally), actually working with real data is usually not. In many courses, programming is not covered, either, only the theory; learn, or know, programming on your own.

Thus the very common answer from developers and DBA's alike: "That doesn't happen, I've looked at the [SQL | C | VB | Language(s) used] code, and it doesn't [do | allow] that!", to which my response is "Look at the data; yes, right there, see it?", to which their response is "What? That shouldn't happen!"

Understanding the way data can be mutilated is the first step to admitting that something should be done to prevent it, preferably at the lowest possible level, to prevent screwups from each higher level from being permanently stored.

aparks Old Hand Points: 380 More actions · Answer 5

I am a developer in a mid-sized organization. I have inherited a legacy system that rests on a SQL 7.0 database. I have convinced management to upgrade to SQL '08. I have been heavily influenced in the past by a very strong DBA and I understand the importance of good design and careful planning of both the schema and the application itself. Although I have deadlines to answer to and work for the same type of management mentioned in this thread, I want to do things correctly. This requires constant learning and refreshing understanding as our tech world continues to evolve.

We do not have a DBA by the way. I have to work both sides...

My question is: what is the most effective learning plan or set of materials that I can consume that will enable me to deliver the best (and technologically modern) products; Proper schemas, efficient applications and effective data delivery?

Jeff Moden SSC Guru Points: 1004339 More actions · Answer 6

Tony Savoie (9/29/2010)
I am currently stuck in the scenario Old Hand describes......with the addition of "rock star" developers who design their own databases, in Access, do all of their .Net development against it.
Only when they feel it is ready for UAT do they send the Access file to me "to upsize" or they do it them selves on a dev box and ask the dba to backup/restore to another box for UAT.
The DBA then becomes the bad guy for holding things up by wanting database changes. The devs are perfectly happy with columns named "Default", "PostalCode/Zip Code".....or tables named "Tbl Inventory Items in Error / Not Found".
I am at my wits end trying to get this place running properly. I've only been here a year and a half and feel like I'm making no progress as everything is a battle. 52 servers - 1200+ databases - 2 dba's - the other dba was hired 5 months ago - they've gone through 5 dba's in 5 years.....nobody is "getting it" 🙁

What is written down in your company in the form of "standards"? If the answer is "nothing", then things are operating just exactly the way I'd expect them to be.;-)

Write a set of standards. Get management buy-in. Perform 100% code reviews to enforce it. It'll be a huge PITA at first just because everyone hates change and will fight it like crazy... but it's definitely worth it. Think of it as forced process impromement on steriods that will save huge amounts of development, test, and rework time. The company that I imposed such standards for went from an 80% rework/reject status during testing to about 1%. Other improvements just happened sort of naturally after that.

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

OCTom SSChampion Points: 11785 More actions · Answer 7

I have a hunch that designing databases and developing systems is just a tad more complicated than laying tile. 🙂

I learned database design as I went along in my career. I picked up design tips and took a few classes in design theory. Most of what I learned has been through experience and individual investigation. This has made much easier with the advent of the internet and the web.

I typically spend as much time with database design as I do with coding. It's so important to set the groundwork in the database before any code is written.

michael.wiles Old Hand Points: 302 More actions · Answer 8

I had 2 comments in regards to the above article.

1) No matter how much learning or reading about SQL Server where most answers are "depends", it would be nearly impossible not to make a few mistakes here and there. You seem to definitely have to learn from any mistakes.

2) When it comes to application design, there seems to be a couple of different ways to do it. A) Do it right with the luxury of starting from scratch, B) Do the best you can to improve what is there, or C) Do what you can within the allocated amount of resources which may result in the less perfect solution. I'm sure we all would love to always do A or B, but occassionaly, we may be forced with option C sometimes.

In summary, I'd have to say that it is impossible to do things perfectly lest you never start. And that sometimes you are nto able to deliver as great of a solution as you'd like due to constraints outside your control.

niall.baird Hall of Fame Points: 3468 More actions · Answer 9

Tony Savoie (9/29/2010)
I am currently stuck in the scenario Old Hand describes......with the addition of "rock star" developers who design their own databases, in Access, do all of their .Net development against it.
Only when they feel it is ready for UAT do they send the Access file to me "to upsize" or they do it them selves on a dev box and ask the dba to backup/restore to another box for UAT.
The DBA then becomes the bad guy for holding things up by wanting database changes. The devs are perfectly happy with columns named "Default", "PostalCode/Zip Code".....or tables named "Tbl Inventory Items in Error / Not Found".
I am at my wits end trying to get this place running properly. I've only been here a year and a half and feel like I'm making no progress as everything is a battle. 52 servers - 1200+ databases - 2 dba's - the other dba was hired 5 months ago - they've gone through 5 dba's in 5 years.....nobody is "getting it" 🙁

I'm also one of those who has to 'upsize' MS Access db's. I think that this is probably because of the cost to design a database application properly, especially when the 'power user' or original designer of the Access db only started it to help them in their job, and built on it from day to day, with only a germ of an idea of what it was eventually going to look like an what it was eventually going to do. Then Bruce looks over his shoulder one day and says "I could use that too", then Fred, then Mary etc etc, until the badly designed db (for want of a better word) becomes "Mission Critical". Somewhere along the track, the db becomes too large & unwieldy for the original "designer" to manage, and money is found from somewhere to upscale to SQL Server. Unfortunately for most of us, that money is nowhere near enough to redesign the database & front end completely, so you're stuck with pretty much just upscaling it.

Mind you, that all being said, it has made me quite a lot of money over the years 🙂

Steve Jones - SSC Editor SSC Guru Points: 736212 More actions · Answer 10

You absolutely will make mistakes when you design. The point of the editorial isn't that you should make perfect design or that you should spend time ensuring everything is right, but that you should make an investment to learn what is good design. Question what you do, and try to find out if you can do things better.

Ultimately you need to move forward on the project, but there's no reason you can't reevaluate the design later, get input from others, and decide what was good and what wasn't.

Whether you can actually change things is another story, but at least you can learn for the future.

Tony Savoie Mr or Mrs. 500 Points: 511 More actions · Answer 11

LOL.

I can see the situation you are describing, but here its on purpose. Every app starts out with an Access db (dont even want to call it that) that the dev uses locally. When they are happy with the app they send the file to the dba to upsize. We dont even hear about the apps till this point. It's nuts.

david_wendelken SSCrazy Points: 2388 More actions · Answer 12

Tony Savoie (9/30/2010)
LOL.
I can see the situation you are describing, but here its on purpose. Every app starts out with an Access db (dont even want to call it that) that the dev uses locally. When they are happy with the app they send the file to the dba to upsize. We dont even hear about the apps till this point. It's nuts.

That statement isn't true.

Excel is the most popular "database" out there.

Access is 2nd. Count your blessings when you start with tables instead of cells.

david_wendelken SSCrazy Points: 2388 More actions · Answer 13

A good database design doesn't have to take a long time to do.

That includes written business definitions for each table and column, plus a list of specific business rules that need to be enforced on the data (that the database constraints cannot handle).

The time it takes to provide the above information is about 20 times less than the time it takes to explain the same thing verbally to the developers one by one - and clean up the pooh afterwards because they didn't get it.

SQLRNNR SSC Guru Points: 281334 More actions · Answer 14

Great points. That little attention to detail and taking just a little bit longer to do good design in the beginning will inevitably save time down the road.

Jason...AKA CirqueDeSQLeil
_______________________________________________
I have given a name to my pain...MCM SQL Server, MVP
SQL RNNR
Posting Performance Based Questions - Gail Shaw[/url]
Learn Extended Events

niall.baird Hall of Fame Points: 3468 More actions · Answer 15

They're all great points, but my personal experience has been that its the Business users, who think they can develop an application, not the "real" developers, that are the problem.