?

Log in

No account? Create an account

ru_java


ru.java

все о языке программирования java


Previous Entry Share Next Entry
Вопрос по БД
vybe wrote in ru_java
Всем доброе время суток. Возможно вопрос не туда, но думаю тут народ сможет мне это разъяснить. А то что-то туплю..
Значит он относится к проектированию БД.
Предположим у меня есть сущность "Пользователь". И один из атрибутов этого пользователя - город, в котором он живет.
Сомо собой, городов в итоге будет ограниченное колличество. Они будут постоянно повторяться. И вот тут затуп.. Я вижу 3 варианта:
1) Оставить поле Город в таблице Пользователи, проиндексировать его и оставить борьбу с избыточьностью на совести СУБД.
2) Создать таблицу Города с сурогатным ключом (какой-нибудь ID) и полем для названия города. Вынести ID как форин кей в таблице пользователей. При этом придется следить за не вставлением дубликатов в таблицу городов.
3) Создать таблицу Города с натуральным строковым ключем - названием города, и сделать под это поле форин кей в таблице пользователей.

У каждого подхода я вижу свои приимущества и недостатки, но все таки как правильно и главное почему?

UPD:
Я привел это только как пример. Возможно неудачный. Допустим есть только города и города с одинаковым названием считаются одним городом. Т.е. мне там нужно точно без дупликатов.
Не обращайте внимания на суть - у меня другие бизнес процессы и структуры данных, которые просто было бы безсмысленно объяснять.

  • 1
Второй. И вот почему:
1. Люди живут не только в городах. В деревнях, сёлах и посёлках тоже ещё не все вымерли.
2. Тебе не надо следить за невставлением дубликатов в таблицу городов, поскольку населённые пункты с одинаковым названием встречаются. Ты знаешь, сколько населенных пунктов с названием "Ивановка" в России?

Тут вот в чем дело... Я привел это только как пример. Возможно неудачный. Допустим есть только города и города с одинаковым названием считаются одним городом. Т.е. точно без дупликатов.

Подвохи видите, но никому не расскажете;)

Встречный вопрос, вам нужно будет делать отчёт по городам?

ну основные я вроде описал, а недостатки натуральных ключей как таковых я думаю все понимают.

Да, мне нужно будет выбирать список всех городов. И это одна из возможных проблем с подходом 1, потому как при этом придется перебирать всех пользователей.

2 вариант правильный. Города(вернее "Населенные пункты") могут иметь одинаковое название. И чтобы не извращаться и не придумывать естественный ключ в таком случае, проще всего использовать суррогатный.

смотрите апдейт к топику.

Создать таблицу Города с полем "имя города", а у пользователя хранить айди города.

ну это опция 2..
с учетом того, что придется следить за отсутствием дубликатов...
какие приимущества перед другими вариантами??

2 правильно.
то, о чем вы говорите, называется нормализацией, см. http://en.wikipedia.org/wiki/Database_normalization
http://ru.wikipedia.org/wiki/Нормальная_форма
кошерно доводить бд по крайней мере до третьей нормальной формы.
использовать индексы для нормализации вместо реляционных моделей - это самое меньшее не соответствует идее реляционного представления данных.
см. также google о достоинствах/недостатках нормализации/денормализации данных.

"Правильного" варианта в природе нет.
Всё зависит от ситуации, а чаще от личных убеждений.

Joe Celko, например, с пеной у рта доказывает
что нужно использовать естественные ключи.

Также голосую за вариант со справочником городов из КЛАДР-а.
Если давать пользователям заполнять -- там будет бардак.

Всем спасибо. Я сделал свои выводы.
У меня будет необходимость нечеткого поиска по городам, потому буду выносить в отдельную таблицу. С сурогатным ключом. И с использованием unique поля.

Для OLTP вариант 2 с unique constraint по имени если требуется
Для OLAP вариант 1

pervij variant.

esli nuzhno vivesti spisok vseh gorodov, to:
SELECT DISTINCT.

  • 1