My question:
How would I implement a database design on the back-end and the front-end to accommodate a varying number of address lines such as AddressLine1, AddressLine2, AddressLine3, etc. into infinity while maintaining an intuitive front-end user experience. I want this to maximize the cleanliness and ease of merging documents later on once the database has been developed. Some addresses have only one street line while others can even have five or maybe more.
Background:
I am very new to data modeling and database design. I don't yet understand the consequences that database modeling will have on how the forms on the front-end will have to be designed and the headaches that may go along with a particular design. Therefore, I'm not sure if what I'm seeking is a big mistake.
I'm designing a case management database for a law firm. We plan to create a separate Addresses table and have a many-to-many relationship between the people/entities and the addresses--i.e., many people/entities may have many addresses and the same address may belong to many people/entities.
Thank you!
Typically, for an address, the data is not normalized over the lines. So, an address table would just have fields like AddressLine1 and AddressLine2.
The bigger geography information (example: city, state, country, postal code) would be stored in separate fields in the address record.
The reason for this is quite practical. Addresses are typically printed, and there is a limited amount of printing space available. If there are four lines, for instance, you have the name, address line 1, address line 2, and city/state/country/postal code.
If you really needed to store an unlimited number of lines, you would do it with an AddressLines table. The AddressLines table would have fields, such as:
However, this seems like overkill.
Your bigger problem is standardizing addresses. Have you given that any thought? (You know: "101 6th Avenue", "101 Sixth Ave.", and "101 Avenue of the Americas" are all the same address in New York City.)