使用 SQL 创建表并利用元数据

发布于 2024-10-31 19:51:39 字数 324 浏览 2 评论 0原文

做作业,要求我做一个数据库的表,该表对应于百货商店的一个分店,该表必须包含以下信息:

CREATE TABLE STORE
(

id_store varchar (50),
name_store varchar (50),
city varchar (50),
country varchar (50),
region varchar (50)
);

我的问题是我们需要有城市、国家和地区的字段,还是通过元数据信息,我可以设置一个模式,通过主键 id_state 的分解来提供该信息?例如,前 3 位数字对应于国家/地区,接下来的 3 位数字对应于城市,依此类推。

To homework, asking me to make a table of a DB, the table corresponds to a branch of a department store, this table must contain the following information:

CREATE TABLE STORE
(

id_store varchar (50),
name_store varchar (50),
city varchar (50),
country varchar (50),
region varchar (50)
);

My question is do we need to have the fields of city, country and region, or by the metadata information I can set a pattern for which that information is provided by the decomposition of the primary key id_state? For example the first 3 digits correspond to the country and the next 3 correspond to the city and so on.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

七七 2024-11-07 19:51:39

您永远不会希望创建一个系统,其中主键尝试对有关行中其他属性的数据进行编码。这是通往巨大心痛和巨大痛苦的道路。

  • 这使得更新变得非常困难。例如,如果您确定墨西哥属于中美洲地区而不是北美地区,则您必须检查并更新墨西哥商店的所有主键以及系统中引用这些主键的每个位置。这是一项巨大的工作量,实际上不太可能完成,而且就运行时和测试而言,这是一项非常昂贵的操作。
  • 它使得查询数据变得更加复杂。现在,如果您想查找墨西哥的所有商店,则必须编写代码多次调用 SUBSTRINSTR 来解析一行位于哪个国家/地区。与单独的列相比,索引和优化器理解要困难得多。确保没有“MEX”、“mex”和“mx”行都代表墨西哥也更加困难。
  • 它违反了正常化的一般原则。城市、国家和地区是商店的单独可识别属性。应该为它们提供一个单独的列。

You would never want to create a system where the primary key tries to encode data about other attributes in the row. That is the path to great heartache and much suffering.

  • It makes updates terribly difficult. If you decide that Mexico belongs with the Central American region rather than the North American region, for example, you would have to go through and update all the primary keys for your Mexican stores along with every place in the system that those primary keys are referenced. That is a tremendous amount of work, it is incredibly unlikely to actually get done, and it is a very costly operation in terms of runtime and testing.
  • It makes querying the data much more complicated. Now if you want to find all the stores in Mexico, you have to write code that makes multiple calls to SUBSTR and INSTR to parse out which country a row is in. That is eminently more difficult to index and for the optimizer to understand than a separate column. It's also much harder to ensure that you don't have 'MEX', 'mex', and 'mx' rows all representing Mexico.
  • And it violates general principles of normalization. City, country, and region are separate identifiable attributes of a store. They should be given a separate column.
~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文