September 4, 2014 at 4:35 am
Hi Friends,
I have worked on different DB projects. All the companies I worked will design DB/tables directly in sql server management studio. Means they do each table when they decide to suit their requirement.
My question is
What is the actual procedure to design a database for an application? (any tools to be used)
How do we decide whether the design is correct or not/
What do we do if the design of a table is not supporting in the middle of development? How do we resolve this?
Please reply
September 4, 2014 at 7:00 am
a2zwd (9/4/2014)
Hi Friends,I have worked on different DB projects. All the companies I worked will design DB/tables directly in sql server management studio. Means they do each table when they decide to suit their requirement.
My question is
What is the actual procedure to design a database for an application? (any tools to be used)
There are no necessary tools for doing a database design. You can use a piece of paper or a white board, design the database and build it all with T-SQL. However, people doing large scale database design frequently take advantage of an E/R tool (Entity Relationship). My favorite is ERStudio by Embarcadero. It can also generate your T-SQL for you (although I'm not crazy about all the choices it makes, so I sometimes edit what it does).
How do we decide whether the design is correct or not/
Well, there's the rub. Did you design the database so that it enables you to correctly and efficiently capture the information necessary for the business and application? Further, once the data is captured, can you get that information back out of the database correctly and in an efficient manner? The shortest possible answer to these questions is, testing. Lots and lots of testing. You can't just "know" that you got it right. You need to validate that you got it right.
What do we do if the design of a table is not supporting in the middle of development? How do we resolve this?
Please reply
Change the design. Refactoring, modifying the design and structures of code, is as much a database function as it is an application function. You have to allow for the fact that you probably didn't get the design right the first time, or, that the requirements weren't communicated correctly, or, that the requirements changed, or, pick your reason for needing to make a change. Change is common. Plan for it. That's a big part of why you should, as much as you can, develop databases the same way you develop applications. This means getting your database into source control, implementing a continuous integration environment for deployment validation, and all the other attendant processes and issues that come with team-based development.
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
- Theodore Roosevelt
Author of:
SQL Server Execution Plans
SQL Server Query Performance Tuning
Viewing 2 posts - 1 through 1 (of 1 total)
You must be logged in to reply to this topic. Login to reply