Quote:
|
What is it your database actually holds information about? Is it actually shoes? It just seems unwise to get recommendations on how to design a database but not tell us what the database is going to hold.
|
It's not actually shoes, but the abstraction is close enough to be relevant. I'm also not looking to have anyone design it
for me. What I'm looking for here is advice on good practices and proper design. I could fairly trivially redesign this to work adequately (far better than it presently does, at that). Redesigning it to be merely
okay isn't really why I'm here.
Quote:
|
It would also help if you could provide more detail as to what benefits you want from the new design over your existing design. As Rudy has already pointed out - if there are no real benefits from all this change other than it being better normalised then someone at some point is going to ask why you spent a load of time and money making all these changes while running the risk of ending up with a system that might not be as effective as the original system.
|
The primary benefit I'm expecting to get from this is data that is actually reliable, highly representative of reality, and is actually robust enough to be utilized beyond the limited capacity in which it is presently.
As I said before, it currently "works" only in some regards. In others, it leaves a lot to be desired. An Excel sheet would "technically work" for this in some regards, too and, similarly, if I'm really bent on it, I *could* use a hammer to pound in a screw - that's hardly the right way to go about it, however.
If nothing else, its current format requires duplicate data entry for every line item of every order, and that, all by itself, is ghastly.
Quote:
|
Can I also ask why you don't just have a single field holding a short description of the spec ie "black laced stileto shoes" and save yourself all the hassle?
|
There WILL be a "shortdesc" field, but the inclusion of such is not some cureall - if it were, you may as well ask, "Why bother with normalization - or even relational databases at all, for that matter - when you can just jam everything into an Excel sheet and call it a day?" So, yes, I'll have a description field, but its function will be for easy recognition and differentiation of specs - a convenience - as a description really should be, not as a lazy method of storing individual datapoints. At present, a description field is basically
all there is. That's not a very reliable way to keep track of information. If, for example, I want to know how many
stiletto shoes we have sold, I have to hope that, for all of the (potentially thousands) of different specifications calling for a stiletto heel, nobody accidentally misspelled "stiletto" somewhere along the way.