另请记住,即使一个用户可以在系统中拥有多个地址,您最不希望发生的事情是将多个用户绑定到同一个 address_id。它们通常更适合作为用户(或其公司)的详细信息,或者作为后者的 1-n 相关详细信息;从来没有。否则,UI 问题很快就会出现,有人总是会错误地编辑用户 B 的地址,因为后者恰好与用户 A 共享该地址。
In my experience, you need country, state, city, zip, address.
Only the first three/four are convenient to filter users. Enum fields are very suitable for the first two. The next two are ideally validated using APIs -- this will spare you the hassle of needing to maintain a list of valid values.
I've yet to run into any system (though I assume a post office would need it, along with geolocation) that needs the address part to be chunked in individual pieces of data for more precise filtering -- plus, each user has his own way of entering the latter.
Keep in mind that some countries have no state; that others have no zip codes; and that zip code formats vary widely from a country to the next.
Also keep in mind that, even when a user can have multiple addresses in your system, the last thing you want is to tie multiple users to the same address_id. They're usually better placed as details of the users (or their company), or as 1-n related details towards the latter; never n-n. When not, UI issues quickly creep in, and someone will invariably edit the address of user B by mistake, because the latter happens to share it with user A.
Address
id INT PK AUTO_INCREMENT
street VARCHAR
city_fk INT FK
Zip_code VARCHAR
City
id INT PK AUTO_INCREMENT
name VARCHAR
state_fk INT FK
State
id INT PK AUTO_INCREMENT
name VARCHAR
country_fk INT Fk
Country
id INT PK AUTO_INCREMENT
name VARCHAR
user
id INT PK AUTO_INCREMENT
# other details
user_address_mapping # So that user can have multiple address
id INT PK AUTO_INCREMENT
user_fk INT FK # Link to user
address_fk INT FK # Foreign key to address
Address
id INT PK AUTO_INCREMENT
street VARCHAR
city_fk INT FK
state_fk INT FK
country_fk INT FK
Zip_code VARCHAR
City
id INT PK AUTO_INCREMENT
name VARCHAR
State
id INT PK AUTO_INCREMENT
name VARCHAR
Country
id INT PK AUTO_INCREMENT
name VARCHAR
user
id INT PK AUTO_INCREMENT
# other details
user_address_mapping # So that user can have multiple address
id INT PK AUTO_INCREMENT
user_fk INT FK # Link to user
address_fk INT FK # Foreign key to address
# Here user_fk & address_fk should be composite unique key, so that users can not share an address.
Here is one extended database structure for address representation, Advantages with this approach 1. You can add city, country, state later on. 2. it supports edting of city country or state. 3. City is mapped to State and similarely state is mapped to Country. So you will just be storing city in an addrss. You are not needed to store state and country in each address, thus reducing redundancy. 4. You can generate a list of State whenever user chooses a country. Similarely you can generate a list of city when user chooses a state.
Address
id INT PK AUTO_INCREMENT
street VARCHAR
city_fk INT FK
Zip_code VARCHAR
City
id INT PK AUTO_INCREMENT
name VARCHAR
state_fk INT FK
State
id INT PK AUTO_INCREMENT
name VARCHAR
country_fk INT Fk
Country
id INT PK AUTO_INCREMENT
name VARCHAR
user
id INT PK AUTO_INCREMENT
# other details
user_address_mapping # So that user can have multiple address
id INT PK AUTO_INCREMENT
user_fk INT FK # Link to user
address_fk INT FK # Foreign key to address
EDIT: (Thanks to @Denis comment) Or If your contry does not have states (Or you want a generic solution) here is the structure.
Address
id INT PK AUTO_INCREMENT
street VARCHAR
city_fk INT FK
state_fk INT FK
country_fk INT FK
Zip_code VARCHAR
City
id INT PK AUTO_INCREMENT
name VARCHAR
State
id INT PK AUTO_INCREMENT
name VARCHAR
Country
id INT PK AUTO_INCREMENT
name VARCHAR
user
id INT PK AUTO_INCREMENT
# other details
user_address_mapping # So that user can have multiple address
id INT PK AUTO_INCREMENT
user_fk INT FK # Link to user
address_fk INT FK # Foreign key to address
# Here user_fk & address_fk should be composite unique key, so that users can not share an address.
*****************************************************************
Type Field name Displayed name in your form
*****************************************************************
INT id (PK)
VARCHAR(100) country Country
VARCHAR(100) zip_code Zip code
VARCHAR(100) state State, province or prefecture
VARCHAR(100) city City
VARCHAR(100) street Street address
VARCHAR(100) building Apt, office, suite, etc. (Optional)
*****************************************************************
"country", "zip code", "state", "city", "street" and "building" fields will be able to cover almost all addresses in this world as shown below:
*****************************************************************
Type Field name Displayed name in your form
*****************************************************************
INT id (PK)
VARCHAR(100) country Country
VARCHAR(100) zip_code Zip code
VARCHAR(100) state State, province or prefecture
VARCHAR(100) city City
VARCHAR(100) street Street address
VARCHAR(100) building Apt, office, suite, etc. (Optional)
*****************************************************************
发布评论
评论(4)
根据我的经验,您需要国家、州、城市、邮政编码、地址。
只有前三/四项方便过滤用户。枚举字段非常适合前两个。接下来的两个是使用 API 进行理想验证的——这将使您免去维护有效值列表的麻烦。
我还没有遇到过任何系统(尽管我假设邮局需要它以及地理定位)需要将地址部分分成单独的数据片段以进行更精确的过滤 - 另外,每个用户都有自己的进入后者的方式。
请记住,有些国家没有国家;有些国家没有国家。其他人没有邮政编码;而且各个国家的邮政编码格式差异很大。
另请记住,即使一个用户可以在系统中拥有多个地址,您最不希望发生的事情是将多个用户绑定到同一个 address_id。它们通常更适合作为用户(或其公司)的详细信息,或者作为后者的 1-n 相关详细信息;从来没有。否则,UI 问题很快就会出现,有人总是会错误地编辑用户 B 的地址,因为后者恰好与用户 A 共享该地址。
In my experience, you need country, state, city, zip, address.
Only the first three/four are convenient to filter users. Enum fields are very suitable for the first two. The next two are ideally validated using APIs -- this will spare you the hassle of needing to maintain a list of valid values.
I've yet to run into any system (though I assume a post office would need it, along with geolocation) that needs the address part to be chunked in individual pieces of data for more precise filtering -- plus, each user has his own way of entering the latter.
Keep in mind that some countries have no state; that others have no zip codes; and that zip code formats vary widely from a country to the next.
Also keep in mind that, even when a user can have multiple addresses in your system, the last thing you want is to tie multiple users to the same address_id. They're usually better placed as details of the users (or their company), or as 1-n related details towards the latter; never n-n. When not, UI issues quickly creep in, and someone will invariably edit the address of user B by mistake, because the latter happens to share it with user A.
这是一种用于地址表示的扩展数据库结构,
这种方法的优点
1. 您可以稍后添加城市、国家、州。
2.支持城市、国家或州的编辑。
3. 城市映射到州,同样州映射到国家。所以你只需将城市存储在地址中。您无需在每个地址中存储州和国家/地区,从而减少冗余。
4. 每当用户选择一个国家/地区时,您都可以生成一个国家/地区列表。同样,当用户选择一个州时,您可以生成一个城市列表。
编辑:(感谢@Denis评论)
或者如果您的国家没有州(或者您想要一个通用的解决方案),这里是结构。
Here is one extended database structure for address representation,
Advantages with this approach
1. You can add city, country, state later on.
2. it supports edting of city country or state.
3. City is mapped to State and similarely state is mapped to Country. So you will just be storing city in an addrss. You are not needed to store state and country in each address, thus reducing redundancy.
4. You can generate a list of State whenever user chooses a country. Similarely you can generate a list of city when user chooses a state.
EDIT: (Thanks to @Denis comment)
Or If your contry does not have states (Or you want a generic solution) here is the structure.
这取决于您想要如何规范化数据库(仓库或事务)
示例 1:
非规范化,所有内容都在一张表
中表名:用户
属性:用户ID,用户名,国家
要检索的sql:
示例2:
规范化,所有内容都在单独的表
中表名:user
属性:userid、用户名、countryID
表名:国家
属性:国家ID,国家名称
检索的sql:
您需要知道数据库是用来做什么的,以确定“高效”的方式。
Well depend on how you want to normalize the db, (warehouse or transactions)
Example 1:
unnormalized, everything in one table
table name: user
attribute: userid, username, country
sql to retrieve:
Example 2:
normalized, everything in separate table
table name: user
attribute: userid, user name, countryID
table name: country
attribute: countryID, country name
sql to retrieve:
You need to know what the db is used for to determine the "efficient" way.
“国家”、“邮政编码”、“州”、“城市”、“街道”和“建筑物”字段将能够覆盖这个世界上几乎所有的地址,如下所示:
"country", "zip code", "state", "city", "street" and "building" fields will be able to cover almost all addresses in this world as shown below: