designing database

Question

Basically my job is to develop web applications using a database as backend. What I have been doing till now is,
Basded on the requirement of the client,

• I draw a basic sketch of what the tables are ,how they look like
• fields in those tables and some one-to-one or many-to-one or many-to-many relations

Although I am not perfect at these things, I try to figure out how the relations should be from my past projects that I worked on. But there are still some doubts about this in my mind.

If the client asks that he wants a particular data, I try to achieve it either through a direct SQL query or thought the scritp (in most cases PHP), if I am unable to figure out a query at all for that particular request.

Now, here comes my question.

Based on the relationships that I figured out while developing tables, are there any limitations to what a client can ask? What I mean to say by this is, the client will ask that he wants list all the indidual products, their counts, associated category, all the counts of
category, the products in each category and the their prices, sum of all the category prices and the total prices so on so forth.

This is just an example of one request to explain my situation.

Now, if there is any request that can potentially take longer time for the exection, can the developer satisfy this request by breaking down the request? Do I need to tell him why is this break down necessary? What if he feels that I am not capable of doing it in a single shot?

Is every report that he asks for need to be in single query? or will there be any need to itake the help of PHP to proces one loop and based on the values that I get, I put some conditions to apply rules that the client wants?

What is the better way to do this kind of job?

Any views?

Thanks.

Answer 1

This will generally depend on the Database used.

Most queries could be done in a single select, but this shoudl never stop you from looking at Views/Sub Selects/ Stored Procedures .

You should be able to handle most of your queries in this fashion, so I would recomend:

Dont let the output determine how you design the database, this might lead you down the wrong road. You need to stored data in the most normalized fasion suitable to the application.

Answer 2

Lots of questions!

Based on the relationships that I figured out while developing tables, are there any limitations to what a client can ask?

A client can ask for anything really. Clients aren't always rationale. It's part of your job to help the client think through their needs.

What I mean to say by this is, the client will ask that he wants list all the indidual products, their counts, associated category, all the counts of category, the products in each category and the their prices, sum of all the category prices and the total prices so on so forth.

All of these queries sound possible with SQL. To list individual products use the SELECT statement. To get a count use COUNT. To get associated categories use JOINS. Use SUM to get total prices.

Now, if there is any request that can potentially take longer time for the exection, can the developer satisfy this request by breaking down the request? Do I need to tell him why is this break down necessary?

Yes - breaking down the request can help a client understand their needs.

What if he feels that I am not capable of doing it in a single shot?

Convince him otherwise. You don't want him thinking you're stupid if you want to keep his business. :)

Is every report that he asks for need to be in single query? or will there be any need to itake the help of PHP to proces one loop and based on the values that I get, I put some conditions to apply rules that the client wants?

Really depends on your skill level. If you know SQL well enough you can get most of your data in one query. If you aren't as good then you might do a few queries and then loop of them in php. Typically it is faster to do it all in SQL.

What is the better way to do this kind of job?

Are you working for yourself? If so, sometimes it just takes experience to figure out the best way. (and posting to stackoverflow :)

Answer 3

The people paying the bills can ask for anything they want. If what they are asking for really doesn't make sense, then try to make them see reason.

A business requirement shouldn't be changed or removed just because it might be 'hard' to implement.

Design your Database schema to reflect the domain model and normalise to at least 3NF.

Generally, aggregate queries (such as those commonly used to drive reports) can be implemented to utilise indexes and RDBMS specific features to reduce their running time.

Answer 4

You should look at the general principles of requirement specification and represent your client's needs, for example as user stories , which are tasks that a user will wish to perform. You can then cost each user story as a unit of work. It should be possible to work on one user story at a time, so you can agree on the order in which you will deliver them.

It's best to look at each story / query as separate. This way you can add or remove functionality from the schedule depending on the needs of the client. If you spot common patterns, you can refactor them as you go along.

Many problems come from people trying to over-optimise or over-generalise. I would write each query separately unless you find that they are starting to overlap.

Answer 5

It sounds like you just need to improve your data design skills. A properly designed/ normalized database, as astander suggests, won't run into the issues you're worried about. But it takes a lot of time to learn the Right Way to design a database if you just keep learning from mistakes. When I was starting out as a web dev, I found Database Design for Mere Mortals a huge help in showing you how to avoid painting yourself into corners. There's a companion book about how to write good queries on your databases as well. The two books won't teach you everything there is to know, but they give you a great foundation.

Answer 6

It sounds like you are lacking a bit in your confidence. These are the kinds of problems developers face every day. I think it's good that you recognize a possible weakness and are taking steps to improve. Take some time to learn more about databases and queries.

That said let me answer some of your questions directly:

Now, if there is any request that can potentially take longer time for the exection, can the developer satisfy this request by breaking down the request?

• Yes you can break down the request. Not every request can be satisfied in a single query.

Do I need to tell him why is this break down necessary?

• Only if he asks. As long as you meet the requirement you should be fine. If he knew how to do it a better way then why did he hire you?

What if he feels that I am not capable of doing it in a single shot?

• Once again, if he knew a better way to code the database and reports then why did he hire you?

Is every report that he asks for need to be in single query? or will there be any need to itake the help of PHP to proces one loop and based on the values that I get, I put some conditions to apply rules that the client wants?

• No, not everything can be done in a single query, it depends on the complexity of the report.

Answer 7

The design of you relational database will have a huge impact on what can be done (in an effective way) or not. I tend to say it is the most crucial part of your application.
Your process for drawing you tables design is ok. but after that you should review your different Uses Cases and see (with just a pencil and paper) if your database design is able to cope with each of them.
You could then discuss with your client to make sure some cases will never happen. ("eg: Can you confirm that a Product will always belong to 1 and only 1 Category").

That said, the client can, indeed, ask anything in the specs. You are free to accept, refuse, or explain to him why his specs are unrealistic. If you develop a for a fixed price without clear specs, you're in a bad situation, and it's your fault...