2014-10-29 1 views
0

Предположим, у меня есть объект, например:Должен ли я создать новый объект только для одного (строкового) поля?

Человек

-id 
-name 
-address 
-phone 

А потом я хочу, чтобы человек, чтобы иметь что-то, что является строкой, и может быть повторен много раз для каждого человека , например, окрестности, это то, что я думаю, что я должен делать:

Человек

-id 
-name 
-address 
-phone 
-idNeighborhood 

и создать новую таблицу

Район

-id 
-name 

И, конечно же, idNeighborhood является внешним ключом к идентификатору соседства.

Теперь я думал, что мне придется каждый раз приступать к СОЕДИНЕНИЯМ (скажем, я буду использовать окрестности в 90% случаев, когда я хочу использовать кого-то), так, это неправильно?

Person

-id 
-name 
-address 
-phone 
-neighborhoodName 

, в котором я спасу имя города, но, конечно же, будет повторяться много раз (в другом случае я бы повторить много идентификаторов .. так ...).

Кроме того, в моем конкретный случай, соседство никогда не будет расти, оно всегда будет иметь имя, поэтому я думаю, что это лучше сделать, но я не уверен. Единственное, что я считаю недостатком, это то, что я не могу сделать индекс окрестности, а затем он будет медленнее или нет?

+0

Почему все люди EF думают, что присоединение - это дьявол? –

+0

Кроме того, почему у человека было более одного района? –

+0

@AaronBertrand Я никогда не говорил, что у человека будет более одного соседства, но в одном районе будет много людей. И это не то, что объединяет дьявола, просто в каждом случае мне придется делать СУШКИ повсюду. –

ответ

1

Это вопрос о том, что вы хотите модель. Вы должны моделировать вещи в своей базе данных, которые имеют отношение к проблеме, которую вы пытаетесь решить с помощью вашей системы.

Вы заинтересованы в соседствах как своей собственной?

Некоторые причины вы хотели бы сделать окрестности таблицы: -

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

Обратите внимание, что вы можете применить всю эту же логику к столбцу имен. Но вы сделали бы это только в том случае, если ваша база данных была около имена людей, так же, как вы должны сделать столбец окрестности, если моделирование окрестностей поможет решить проблему, которую вы решаете.

+0

Спасибо! Это было действительно полезно, но здесь был еще один вопрос: допустим, я сделаю много запросов, фильтрующих по соседству, например, получите всех людей, которые находятся в окружении XX, тогда дело с идентификатором будет быстрее, не так ли? Или я могу сделать индекс поля varchar (имя окрестности во втором случае)? –

+0

Если вы хотите найти всех в определенном районе, идентификатор будет быстрее, потому что он будет меньше и, следовательно, меньше ввода-вывода и т. Д. Если вы хотите сделать что-то вроде «% blah%», то, скорее всего, быстрее его получить в человек таблица напрямую. Я бы не основывал свое решение на этом аспекте производительности, если вы не думаете, что у вас будет так много строк, что это действительно важно. В этом случае выполните некоторые тесты. –

0

На самом деле это зависит от вашего требования. Если вам нужно отобразить детали района, такие как NAME, PROFESSION и т. Д. В вашем приложении лучше использовать первый подход. Создайте объект с обязательными атрибутами.

Если вы действительно не нужны эти детали в любом месте о вашем районе и вам просто нужно имя, вы можете пойти со своим вторым подходом

Смежные вопросы