физическая модель БД и ее адекватность

[supercranberry]

Здравствуйте, уважаемые форумчане.

Хочу задать вопрос по физической модели БД.

Описание предметной области:
Есть установка. Она датирует органические образцы ( определяет возраст образца). Сам образец отражен в табл Sample.
Проект к которому он принадлежит в Project. У проекта есть заказчик - Customer.
Для проекта и заказчика созданы словари - страна , регион , город (Сountry, Region, Town).
При анализе, от образца (Sample) отделяют кусочек и сотрудник (Employee) его датирует
(то есть у образца Sample может быть несколько значений возраста- Age), что отражено в Sample analysis.
В организации мало сотрудников, поэтому нет необходимости создавать отделы и т.п. Имён и контактов достаточно.

Хотелось бы узнать адекватна ли модель и правильно ли я понял, что словари (country, region, town) нужны для того , чтобы при наполнении базы пользователь не совершил ошибку
и не написал Архнгльск, вместо Архангельск?

Заранее спасибо.

[AlexDem]

Чтобы понять, насколько адекватна модель, не хватает описания задачи. Например, у Вашего проекта есть город, где он, видимо, выполняется. Этот город может отличаться от города, где находится заказчик. Этого в описании нет. Может ли проект переехать в другой город? Тогда что, просто поправить реквизиты в БД? Если нужны отчёты за прошлые периоды, такая правка может быть некорректной. И почему-то связь с городом идёт по почтовому индексу, а ведь на один город может приходиться несколько отделений связи (и разных индексов).

[supercranberry]

Спасибо за ответ.

Проект - место археологических раскопок. То есть переехать он не может. Там берут образцы и потом анализируют их. Сам анализ проходит всегда в одной лаборатории( для нее эта БД и нужна).

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

ГОРОД ИНДЕКС
Псков - 180001
Псков - 180002
Псков - 180003
...
...
и каждый город будет определяться однозначно.

Видимо, правильнее использовать ID, как в Region и Country?

[AlexDem]

supercranberry в сообщении #759658 писал(а):

Видимо, правильнее использовать ID, как в Region и Country?

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

-- Вс сен 01, 2013 21:46:13 --

supercranberry в сообщении #759658 писал(а):

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

Тогда Вам в справочник один и тот же город много раз придётся вбивать. Не страшно, в принципе, но как-то не очень гладко.

[supercranberry]

Еще раз обдумаю, спасибо.

[NT2000]

Не понял заморочек с post code.
Учетная запись Customer - содержит улицу, значит предполагается вести переписку, ну и как же без post code?
А то, что в словаре Town, город например Псков, несколько раз ну и что?
Огранизуйте запрос по уникальному имени города и все дела.

PS. Зная почтовый индекс - однозначно определяется город.
Зная только город - всегда можно найти индекс ( например для города Псков, возвратный индекс Псков - 180000 - Главпочтамт).

PPS. Справочники "Город-Почтовый индекс" по РФ (да и по СНГ) - собственно уже готовые можно использовать (ничего не надо вбивать).

[AlexDem]

А зачем индекс в справочник-то пихать? Их там довольно много: вот, даже все улицы прописаны.

[NT2000]

Можно и улицы, но в таком случае возможно неоправдано большой по размеру будет таблица (если использовать готовые справочники).
В принципе, всё зависит от цели справочника.
Я высказался только по предложенной структуре Town,
в ней почтовый идекс и есть то самое - ID, о котором ТС и вспоминал.

[AlexDem]

Индекс можно и простым полем завести. Кстати, можно тогда в справочнике городов иметь индекс Главпочтамта, первые 3 цифры которого использовать для проверки набираемого вручную значения - в случае чего, далеко посылка не уйдёт.

В общем, как всегда, вариантов много.
(Хотя дублирование в справочнике мне всё равно не нравится).

[NT2000]

Ну вообще-то я и имел ввиду post code - 6 знаковое (char) поле = Primary key,
ни какое не long или automatic number/counter.
Просто для ТС это и будет тоже самое, что ID.

[AlexDem]

Я это понял. Я "post code" ("индекс") предлагал простым полем сделать, без связи со справочником, а проверку делать программно после ручного ввода - как Вы и намекали, видимо, в случае с Главпочтамтом:

NT2000 в сообщении #759685 писал(а):

PS. Зная почтовый индекс - однозначно определяется город.

.

-- Пн сен 02, 2013 09:08:01 --

AlexDem в сообщении #759722 писал(а):

индекс Главпочтамта, первые 3 цифры которого использовать для проверки набираемого вручную значения

Хотя это не пойдёт, сейчас посмотрел для Москвы - там уйма разных индексов.

[NT2000]

AlexDem в сообщении #759782 писал(а):

Хотя это не пойдёт, сейчас посмотрел для Москвы - там уйма разных индексов.

Что не пройдёт? Почему не пройдёт?

Повторю еще раз: Почтовый индекс однозначно определяет город.
Например :
123103 - Москва, МГУ тер
107076 - Москва, Матросский Б. пер
129594 - Москва, Марьиной Рощи 6-й проезд
и т.д.

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

PS. А вот обратная операция - только по названию города вписать в учетную карточку Customer почтовый индекс, это да, несколько сложнее.
Вот тут и надо делать некоторые натяжки и выборка по уникальным именам городов и есть такой определенной натяжкой.
В 99% процентах даёт положительный эффект.

[AlexDem]

NT2000, да я просто считаю, что индексу не особо нужен справочник для проверки, так же как и улице, например. Поэтому это я так - попытался предложить простое решение, но оно не прошло. Ваши предложения я ни в коем разе не оспариваю, поэтому повторять для меня ещё раз не нужно