Форум: "Базы";
Текущий архив: 2002.09.19;
Скачать: [xml.tar.bz2];
ВнизПосоветуйте как правильно и как проще - РАБОТА СО СПРАВОЧНИКАМИ Найти похожие ветки
← →
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 строк
Можно, конечно, профильтровать по группам. Но во-первых, такое поле должно быть в БД, а во вторых, замучаешься фильровать, если групп много, а наименований по каждой - с гулькин нос (такое бывает часто-густо у частных предпринимателей - торгашей).
← →
Hro (2002-08-29 23:23) [9]>> MsGuns Зачем использовать символьные поля для кодов, которые ты почемуто показываеш менеджеру, мне несовсем понятно. Это я могу понять разве что тебе приятно формировать эти сокращения или ты очень хочеш нагрузить пользователя. Ведь намного проще иметь справочник следующего вида:
ID int notnull autoincrement
NAME varchar(XXX)
написать и вообще забыть про эти коды.
← →
Jeer (2002-08-29 23:45) [10]MsGuns © (29.08.02 17:58)
Вы опять не вполне правы.
Не надо смешивать сущности, необходимые для создания логически внятной базы и сущности, необходимые для устойчивого(безошибочного, удобного, etc ) распознавания объектов человеком.
Это часто совсем разные вещи.
Без обид - но вот это полная ересь.
>КфВМшСв,КфВКис,КфКЦрНс
Да, иногда приходится использовать аббревиатуры, но только не в качестве ключа и не более 3-5 символов - иначе труба. User будет вынужден учить Ваш новый язык.
Используются абр. в качестве средства для быстрого доступа, поиска к более длинным обозначениям.
Я их иногда применяю, но в общем случае - отказался.
← →
Jeer (2002-08-30 00:00) [11]В качестве примера, приведу форму.
http://www.recop.hotmail.ru/form.png
Хорошо видно, что аббревиатурное поле имеет повторения.
При небольшой длине этого не избежать, а при большей - трудно запомнить, да и отличия от полного имени уже невелики.
Так, что бессмысленно строить ключ или уникальный индекс по ним.
Аббр. поля используются для быстрого поиска и не более того.
Индекс строится не уникальный.
Страницы: 1 вся ветка
Форум: "Базы";
Текущий архив: 2002.09.19;
Скачать: [xml.tar.bz2];
Память: 0.48 MB
Время: 0.007 c