1

I am developing a CRM application that stores some data on companies we work with. Such as for example: CEO name and physical address of their head office. I will often need to look up for companies located in particular city and then sort the search result by street name.

I know that proper solution will most likely be something like an address column of the integer type, which will point to the address table, which itself will contain other columns like state, city, street, housing_number, office_number all of which will itself be either an integers pointing to related tables (city, state, street) or the final piece of data (housing_number, office_number).

The problem is not just the fact that I'm much more comfortable working with something like one or two linked tables, rather than using difficult JOINs across 3, 4 (like the design i supposed earlier) or even more tables, but also that i don't really see the point of not doing something like this:

| id  |      name       |  ceo_name   |    city     |     street       | house  | office |
|-----|-----------------|-------------|-------------|------------------|--------|--------|
|  1  | Company Name 1  | CEO Name 1  | New-York    | 5th Ave          |    22  |     12 |
|  2  | Company Name 2  | CEO Name 2  | New-York    | 44th St.         |    42  |     88 |
|  3  | Company Name 3  | CEO Name 3  | Boston      | Irish Lane       |     2  |     14 |
|  4  | Company Name 4  | CEO Name 4  | Washington  | Tahoe boulevard  |    54  |     19 |

What problem can i ran into if i implement such a solution? I have all atomics so if the need rises i can always implement the 3-NF solution later on.

4

2 回答 2

1

类似 db 应用程序的实际模式，可能用作样板：

在此处输入图像描述

于 2019-01-21T16:51:54.173 回答
1

听听你的第一个命题是正确的书解决方案，但它确实需要在 SQL 和关系数据库中感觉舒服，就像计算机科学中的所有内容一样，这都是效率问题，表有多大？请记住，在 SQL 中，引擎总是绘制所有列，即使您在您的数据中发出一些列，SELECT如果您将拥有更重的数据类型（占用更多内存字节的字符等），那么显然该表将变得越来越重。如果您的使用仅通过 id（主键）来绘制用户，那么无论查询有多大，您的查询都不会真正变慢。

这完全是一个扩展问题，以及在构建数据时你将如何处理这些数据，就像你为未来计划的第一个建议一样，但你现在牺牲了时间。

于 2019-01-18T12:46:21.737 回答