| fezdmwqf |
| Hohlbratze |
 |
 |
| 908 Posts |
| registered: 26.10.2013 |
|
Is This Mysql Database Normalization Form and Structure Design Correct
Descriptors are generally attributes of entities. If not possible to enumerate all probable descriptors in advance, these ought to probably not be in a table.
Cases where you'd probably want a lookup desk for a descriptor are generally exactly where you're constrained in the types of values you can accept. For example, "shoe size" may appear openended, but maybe you merely manufacture certain measurements, so a freeform enter field is not useful. On the other hand, "height" is better saved as a value having a predefined set of units instead of having a search table of all feasible heights.
In your case, you will need an "address" entity with a number of fields that will describe it. Things such as "building number" should be a freeform feedback field. "Building A", "82 1/2", "107B", "3.7", "4/9" and "44290" are valid building numbers. You should just accept a string.
Likewise, road names are hardly a thing you can qualify. Is "Green Way Street" the same as "Green Way St.In . or "Greenway St."? Does it matter? Probably not, as it's just a descriptor. You don't have any way of verifying these kind of, and linking these people together is almost extremely hard, there's way too much rubbing required to get it to operate on a large scale.
Please remember that some places need to have two,Parajumper, three, a number of, or even five lines of address details to identify a location. Britain is one of the worst offenders here, where a official address will include a variety of information.
What you should possibly do is design a table such as "addresses" with fields: address1, address2, address3, address4, address5, city, region, country, postal_code. Your you can cover many anything they'll put at you. Look at the form of data Google Road directions returns for cases.
You seem to be suggesting at some kind of onetomany composition in your question, in which an address could have multiple building names or numbers. Without some sort of sequence indicator, you will have no way of knowing which of these connected records is 1st. That complicates issues significantly.
When worrying about normalization,parajumper, start with the simplest thing that works, and fix any kind of obvious mistakes. If you do not have massive numbers of data to deal with, you are able to usually adjust your schema fairly easily if you haven't overdone it using normalization.
Think first when it comes to "entities" and "properties", and second in terms of "tables" and "columns" which are just an expression of those. If your property can thing can have multiple associations you need to apply normalization. If a property can have a number of values, then you need to understand what kind of values an individual dealing with. If coming from a predefined list of choices, then it should be any lookup table. If it userentered, then validate and/or clean-up as rigorously while practical at the application level, and conserve whatever the result of that is certainly. tadman 2 days ago
A person asking the right questions, but I think an individual overapplying the answers. There is such a thing as too much normalization. Databases that have been normalized to the absolute restriction are extremely frustrating to work with since you will have to consistently JOIN tables collectively to get any purposeful data out of these people. What should be SELECT . FROM addresses Exactly where id=x becomes thirty outlines of complicated SQL. Typically there a balance for you to strike between becoming properly normalized and also being easy to assist tadman 2 days ago
|
