Как сохранить адрес в базе данных

Question

Я занимаюсь разработкой приложения CRM, которое хранит некоторые данные о компаниях, с которыми мы работаем. Например: имя генерального директора и физический адрес их головного офиса. Мне часто нужно искать компании, расположенные в определенном городе, а затем сортировать результаты поиска по названию улицы.

Я знаю, что правильным решением, скорее всего, будет что-то вроде столбца адреса целочисленного типа, который будет указывать на таблицу адресов, которая сама будет содержать другие столбцы, такие как штат, город, улица, жилищный номер, офисный номер, каждый из которых будет сам по себе может быть целым числом, указывающим на связанные таблицы (город, штат, улица) или конечным элементом данных (housing_number, office_number).

Проблема не только в том, что мне гораздо удобнее работать с чем-то вроде одной или двух связанных таблиц, чем с использованием сложных JOIN-ов в 3, 4 (как дизайн, который я предполагал ранее) или даже с несколькими таблицами, но также, что я не вижу смысла не делать что-то вроде этого:

| 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 |

С какой проблемой я могу столкнуться, если реализую такое решение? У меня есть вся атомика, поэтому, если потребность возрастет, я всегда смогу реализовать решение 3-NF позже.

Answer 1

Фактическая схема для аналогичного приложения БД, может использоваться в качестве шаблона:

Answer 2

Прислушайтесь к первому вашему предложению - это правильное книжного решения, но для этого нужно чувствовать себя комфортно в SQL и реляционных базах данных, как все в компьютерных науках, это все вопрос эффективности, насколько большой будет стол будет? Помните, что в SQL движок всегда рисует все столбцы, даже если вы выделите некоторые из них в SELECT, если у вас будут более тяжелые типы данных (символы, которые занимают больше байтов памяти и т. Д.), То, очевидно, таблица будет становиться все тяжелее и тяжелее , Если вы будете использовать пользователя только по идентификатору (первичному ключу), ваши запросы никогда не будут медленными, независимо от того, насколько они велики.

Это все вопрос масштабирования и того, что вы будете делать с этими данными при построении их, как ваше первое предположение, что вы планируете будущее, но жертвуете временем в настоящем.