Посоветуйте как правильно и как проще - РАБОТА СО СПРАВОЧНИКАМИ

← →
RDA © (2002-08-29 10:19) [0]

Ситуация такая есть таблица описывающая организация: название, адрес (юридический, почтовый и т.д.). Есть справочники: области, районы, города, улицы. Как лучше организовать таблицу организации. Связать ее с таблицами составляюшими адрес и хранить в полях организации ссылки из соответствуюших таблиц (номера записей) или конкретно хранить соответствующие значения.
Не будет ли проблем с запросом по выборке из десятка таблиц необходимых значений для представления сведений об организации (интересует фактор времени). Ну и вообще кто-либо может подсказать и поделиться опытом по данному вопросу.

← →
Alexandr © (2002-08-29 10:23) [1]

ты про нормализацию читал?
И что, с классиками спорить вздумал?

← →
Рустем (2002-08-29 10:45) [2]

Действительно, базы должны быть нормализованы.
Только в очень редких случаях допускается не создавать
отдельную справочную таблицу. Это делается только для самых
исключительных случаях, когда самое главное - время выполнения.
Удивительно, что Вы собираетесь разбить базу Контрагентов на
"десятки" таблиц. Что-то трудно представить как.

← →
RDA © (2002-08-29 16:40) [3]

>>Alexandr и Рустем - спасибо за ответы. Где-то подобного и ожидал. Вопрос задал вот почему, где-то чего-то недопонял я в нормализации.
Являются ли следующие таблицы нормализоваными.
1. Области
Название области // первичный ключ не равен нулю. (Varchar 40)
2. Районы
Название // первичный ключ не равен нулю. (Varchar 40)
Назв. области // (Varchar 40);

Построен FK по полю область.

У меня сомнения. Но как правильно не знаю. Дайте пример, на таком простом вопросе, дальше думаю разбирусь. За более сложные примеры из 3-5 таблиц буду благодарен. Можно на мыло. Заранее благодарен.

← →
MsGuns © (2002-08-29 17:26) [4]

Использовать в качестве ключей стринги такой длины - преступление, а для справочников - преступление с отягощающими последствиями. Уважаемый, для этих целей используется КОДИРОВАНИЕ, т.е. доп.КОРОТКИЕ поля, которые собственно и являются ключами и служат для связок, кроме того существенно экономят физ.размер информационной (не справочной) части БД
Грубо говоря, справочник улиц:

Код Название Примечание
-------------------------------------------------
Лен ул.В.И.Ленина
ПрОР Проспект Октябрьской революции

Тогда во всех записях о клиентах, расположенных на проспекте вместо 40 символов (а кто сказал, что их хватит ?), будет записано 4-8
. . .

← →
Jeer © (2002-08-29 17:30) [5]

Таблицы:
ОБЛАСТЬ
ID,
NAME;
РАЙОН
ID,
PARENT, // ссылка на ID.область
NAME
ГОРОД
ID,
PARENT, // ссылка на ID.район
NAME
УЛИЦА
ID,
PARENT, // ссылка на ID.город
NAME

ОРГАНИЗАЦИЯ
ID,
ID_AREA, // ссылка на область и т.д.
ID_RAJON,
ID_TOWN,
ID_STREET,
NAME;

Как минимум

← →
Jeer © (2002-08-29 17:31) [6]

MsGuns © (29.08.02 17:26)

Это совсем не здорово.
ID - integer(word, smallint) - то, что надо

← →
MsGuns © (2002-08-29 17:44) [7]

Пример из 6 таблиц-справочников:

Картотек ОК (отдела кадров)

Таблица состоит из записей-карточек по одной на раждого работающего (и работавшего тоже)

TabNum // Таб.Номер string 6 симв ** Ключ и единственный **
FIO // No commemt
BDay // No comment
..
// Теперь идет поля, связанные со справочниками
CodFS Char(2) // Код сем.пол-я (0-хол,1-жен,2-замуж,..
CodEd Char(2) // Код образования (0-нет,1-срд,2-срдтехн,..
CodPr Char(3) // Код профессии (>100 для ср.размеров предпр)
CodSp Char(3) // Код специальности ( -*- )
CodSt Char(3) // Код должности (тоже до фига)
CodUn Char(3) // Код подразделения (зависит от предприятия)

Для каждого поля поля CodXX есть соотв.таблица-справочник, например, для должностей

SCodSt SNameSt ...
--------------------------------------------
001 Директор
002 Зам директора
003 Гл.бухгалтер
004 Нач.отдела
005 Нач.цеха
006 Инженер-программист
007 Инженер-конструктор
...

В рез-те запись карточки будет иметь вид

000001 Иванов П.Ф. 13.05.67 04 005 037 228 000 000

А теперь представь, что таких карточек тыщ 10, а вместо кодов используются наименования по 40-60 байт каждое, каково ?

← →
MsGuns © (2002-08-29 17:58) [8]

>Jeer
Это совсем не здорово.
ID - integer(word, smallint) - то, что надо

Для скорости - да, согласен безповоротно ! Но а если подумать о человеке, который бу работать с Вашей программой.. Пример
Мелкооптовая торг.фирма.
Менеджер смотрит остатки и хочет посмотреть по конфетам. Видит перед собой складскую картотеку примерно след.содержания

(Ваш вариант)

Код Наименование Остаток
--------------------------------------------------------
1 Конф вес. "Мишка на севере" 12.4
2 Водка "Столичная" 46.0
3 Масло сивочное 200г (шт) 45.0
. . .
394 Конф вес. "Кис-кис" 102.0
395 Конф.кор. "Царевна Несмеяна" 6.0

и так 3600 строк

(мой вариант)

Код Наименование Остаток
--------------------------------------------------------
КфВМшСв Конф вес. "Мишка на севере" 12.4
КфВКис Конф вес. "Кис-кис" 102.0
КфКЦрНс Конф.кор. "Царевна Несмеяна" 6.0
. . .
ЛВСтол Водка "Столичная" 46.0
. . .
БМВСлив Масло сивочное 200г (шт) 45.0
. . .

и так 3600 строк

Можно, конечно, профильтровать по группам. Но во-первых, такое поле должно быть в БД, а во вторых, замучаешься фильровать, если групп много, а наименований по каждой - с гулькин нос (такое бывает часто-густо у частных предпринимателей - торгашей).

>> MsGuns Зачем использовать символьные поля для кодов, которые ты почемуто показываеш менеджеру, мне несовсем понятно. Это я могу понять разве что тебе приятно формировать эти сокращения или ты очень хочеш нагрузить пользователя. Ведь намного проще иметь справочник следующего вида:

ID int notnull autoincrement
NAME varchar(XXX)

написать и вообще забыть про эти коды.

MsGuns © (29.08.02 17:58)

Вы опять не вполне правы.
Не надо смешивать сущности, необходимые для создания логически внятной базы и сущности, необходимые для устойчивого(безошибочного, удобного, etc ) распознавания объектов человеком.
Это часто совсем разные вещи.

Без обид - но вот это полная ересь.
>КфВМшСв,КфВКис,КфКЦрНс

Да, иногда приходится использовать аббревиатуры, но только не в качестве ключа и не более 3-5 символов - иначе труба. User будет вынужден учить Ваш новый язык.
Используются абр. в качестве средства для быстрого доступа, поиска к более длинным обозначениям.
Я их иногда применяю, но в общем случае - отказался.

В качестве примера, приведу форму.
http://www.recop.hotmail.ru/form.png

Хорошо видно, что аббревиатурное поле имеет повторения.
При небольшой длине этого не избежать, а при большей - трудно запомнить, да и отличия от полного имени уже невелики.
Так, что бессмысленно строить ключ или уникальный индекс по ним.
Аббр. поля используются для быстрого поиска и не более того.
Индекс строится не уникальный.

Посоветуйте как правильно и как проще - РАБОТА СО СПРАВОЧНИКАМИ Найти похожие ветки