Работа с родительской и дочерними таблицами

[nikedeforest]

. А вот назначение справочника я не понял. Какой интерес хранить всевозможные сочетания районов, типов домов и санузлов?

В целях избежания избыточности данных. (по крайней мере меня так учили и другого предназначения я для него не вижу ). Кстати в каких еще случаях применяеться справочник?
А оправдать свой справочник я могу таким аргументом (только не смейтесь): эти 3 поля в справочнике являються емкими по ресурсам (ну типа того, что жрут они много, конечно относительно). В придачу число значений в этих полях ограниченно, т.е. районов же не бесконечно много, типов санузлов тоже. А вноситься же эти значения будут всегда, поэтому я решил сэкономить место, храня значения типа varchar в справочнике,
а в дочерних таблицах будут значения типа integer(место много не жрет) и будут эти значения равными значения порядкового номера в таблце-справочнике. Надеюсь не запутал вас .
Oldy, сейчас почитаю, заранее спасибо.
HandKot, ты кажется перепутал или я тебя неправильно понял, но в справочнике поля такие

pn     rayon         tip_doma        sanuzel
1    Ленинский       БК              любой
2

а использование динамических запросов - это результат неправильной структуры данных и плохой признак программирования ИМХО

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

[Dimka]

а использование динамических запросов - это результат неправильной структуры данных и плохой признак программирования ИМХО

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

nikedeforest, ты, пытаясь улучшить одно, ухудшил другое Твой справочник (если убрать искусственный первичный ключ) даже в 2НФ не находится, либо ключом полагать все 3 поля. Если на район приходится несколько типов домов - район будет повторяться, а тип дома не будет полностью функционально зависеть от района. Если же за первичный ключ брать район и тип дома вместе, то опять не будет полной функциональной зависимости санузла. Это 3 различных справочника, 3 различные таблицы, 3 вида данных различной природы, совершенно не связанных между собой сами по себе (не имеющие функциональной зависимости), а лишь опосредовано, через таблицы, которые их используют. И не надо никаких ХП с извращениями, следовательно. Экономия оправдана чем? Получается (если полагать, что справочник в 3НФ находится), что у тебя в районе может быть лишь 1 уникальный (для всех районов) тип дома, и 1 уникальный (для всех типов домов) санузел. На основании здравого смысла (из обычной жизни) могу сказать, что такого не бывает .

[nikedeforest]

dimka, я не понял. Ты предлагаешь вместо одного справочника завести 3. Вообще у меня сложилось чувство, что мы друг  друга не поняли. Понимаешь, мне ненужна взаимосвязь между этими полям в справочнике, мне нужно всего лишь порядковый номер определенного нахождения записи в справочнике, т.е. если Ленинский район у меня в справочнике находиться во второй записи, то я передаю в дочернюю таблицу в поле район номер два, при этом нужная запись типа дома (tip_doma) может находиться под цифрой 4 в справочнике и следовательно в дочернюю таблицу в поле тип дома я внесу значение 4. Ты меня правильно понял???
 Слушай что я нашел, оказывается поддержка хранимых процедур в MySql планировалась ввестись в версии 5.0., у меня кажеться по старее. Я просто пытался внести ХП и ничего не выходило, поискал, порылся и вот, блин узнал. Вопрос возникает, а что так поздно эти уроды опомнились?Щас буду смотреть какой версии мой MySql.

[Dimka]

nikedeforest, но ты понимаешь, что совпадение номеров района и типа дома и санузла - это случайное совпадние? По сути, у тебя будут записи, где заполнено лишь 1 поле, а остальные свободные. И в дочернюю таблицу ты передаёшь ссылку на строку 2 для района, ссылку на строку 4 для типа дома и т.п. Эти ссылки могут вести в 3 разные справочника, и нет никаких проблем с выбором полей и всем прочим. Обилие null совершенно не экономит место. Более того, в рамках такой структуры ты совершенно не можешь отделить по ключу районы от типов и санузлов. Получается полная каша, по которой даже нормальный select не построить без заумных условий выборки.

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

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

[nikedeforest]

Установил себе MySql версии 5.0.1 кажется. ХП поддерживаются, но синтаксис языка непонятный, я как не старался единственной что смог сделать

Код:

create procedure test
begin
select * from sotr;
end

Это заработало, а вот что не вышло

Код:

create procedure test
return (s integer)
as
begin
s=2;
end 

пробовал s:=2, также пробовал returns и прочее.
Короче вывод.
Прошу, покажите мне где можно взять инфу по синтаксису MySql (интересует все, но в первую очередь ХП и триггеры) версии выше 5, желательно на русском, но за неимением такой согласен посмотреть код в какой-нибудь нерусской книженке.

[nikedeforest]

nikedeforest, но ты понимаешь, что совпадение номеров района и типа дома и санузла - это случайное совпадние?

Да я в принципе на это не надеялся. В принципе кажется ты прав. Но я не пойму, ты предлагаешь делать 3 справочника таблицы, в каждом из которых будет по одному полю? А это вообще распространено? Не знаю кажется как-то коряво. Слушай напиши мне в каких случаях еще используются справочники.

[nikedeforest]

Документация по MySql версии выше 5 меня все еще интересует

[MOPO3]

Документация по MySql версии выше 5 меня все еще интересует

Хммм, это где ты такой нашол мускул то ? На официальном сайте есть только MySQL 5.0, и то  Development release с пометкой : use this for previewing and testing new features )
Ничего не путаеш ? Стабильный релиз пока только 4,1 версии

[Dimka]

nikedeforest, везде, давно и постоянно. В таблице состоящей из двух полей ID и Name нет ничего преступного .

[nikedeforest]

Мороз, подожди щас проверю. А есть какой нибудь запрос, чтобы его набрать в консоли и получить версию?

[MOPO3]

nikedeforest, в какой консоли ? у тебя фриБСД или Линукс какой-нибудь ?

[MOPO3]

Под фришкой : pkg_info | grep mysql
Под редхатом : rpm -q | grep mysql

[nikedeforest]

М-да, папка  которую парниша знакомый прислал называется

mysql-5.0.1-alpha-snapshot-win

Да и хранимую процедуру, пусть и простенькую, но ведь заглотил. А поддержка ХП была обещана только в версии 5.0.
Вот еще на WinMySQLAdmin
Нашел такую надпись

Server info 5.0.1-alpha-nt

поэтому вроде как не перепутал. Так видать не судьба мне с хранимой процедурой поработать (документации по видимому нет), а жаль. Хотя может оно и к лучшему, будь проще и люди к тебе потянуться .

[nikedeforest]

Я имел ввиду в консоли где набираються SQL запросы.

[HandKot]

nikedeforest
я имел ввиду, что в справочнике будет всего три поля
КЛЮЧ (его ты хранишь в других таблицах)
ИМЯ ТАБЛИЦЫ (ПАРАМЕТРА в твоем случае это либо, "rayon", либо "tip_doma", либо "sanuzel"
)
ЗНАЧЕНИЕ (собствеено значения)

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

пример

pn          name               znach
1           'rayon'             'Ленинский'
1           'tip_doma'          'БК'
1           'sanuzel'           'Любой'
2           'rayon'             'Сталинский'
2           'sanuzel'            'Раздельный'
...
и т.д.

хотя лучше повторения поля PN лучше не делать

[nikedeforest]

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

[nikedeforest]

HandKot, не очень понял, щас еще поразмышляю (видать торможу).

[nikedeforest]

HandKot,ИМХо неудачная идея, записсей будетмного в справочнике. Зачем, если это можно избежать.

[Dimka]

HandKot, неудачная идея. Справочник не обязательно одно текстовое поле Name хранит. Твоя структура совершенно не расширяема. Вдруг мне для санузла кроме названия ещё что-то добавить захочется? В твоей структуре потребуется добавлять новое поле, которое отнесётся также и к районам и к типам домов, что неверно и черевато ошибками и непонятностями. Структура должна быть такой, чтобы любой специалист, прочитав, смог более-менее понять предметную область. Отклонение от этого правила оправдана лишь жёсткими требованиями к производительности и ограниченностью ресурсов. На современных персональных машинах или серверах не массового пользования (например, маленького или среднего предприятия) можно считать, ограничений нет (для данной задачи, если, конечно, не по всей стране данные собираются).

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

А что рассказать о справочниках? Справочник, он и есть справочник . Набор уникальных значений, определяющих множество допустимых значений в других таблицах (не справочниках). По сути справочник определяет домен данных, но домен динамический, расширяемый и сужаемый (можно добавить новые элементы или удалить старые, отредактировать имеющиеся).

Особый случай со справочниками возникает тогда, когда элементы справочника меняются, но история должна сохраниться в базе. В таком случае справочником выступает пара таблиц: одна содержит некие неизменные понятия (часто абстрактные), а вторая историю изменения значений. Остальные таблицы привязываются к записям истории. Например, есть таблица данных, связанная со справочником налогов, где хранятся название налога и ставка. Что-то там в таблицу вносится до 1 января, считается, всё хорошо. С 1 января ставка налога изменилась. Старые данные требуют для вычисления старую ставку, а новые уже новую. Выходит 2 ставки на 1 налог. Тогда ставка выносится в таблицу истории значений, в историю добавляется 2 даты: начало и окончание действия значения, а само название налога остаётся в главной таблице справочника. В такой структуре уже не страшно менять ставки налога - базу переделывать не придётся. Пример не совсем удачный, так как в подавляющем большинстве случаев все расчёты делаются при внесении записей в БД и результаты расчётов также сохраняются, поэтому в реальной жизни сложный справочник налогов мало где применим.

[nikedeforest]

dimka, спасибо, просвятил.

[nikedeforest]

dimka, я тутчего подумал. Если 3 справочника делать, то получается в каждом справочнике по полю pn (порядковый номер), получается на 2 поля больше. 

[Dimka]

и чего?

[nikedeforest]

и чего?

Так ведь, справочник создавался для избежания избыточности, но при этом он сам начинает создавать эту её самую.
Блин, тяжело найти золотую середину.

[Sla]

Я, например, не вижу избыточности.
справочник это статические таблицы (один раз создал и забыл)
а то что ты предлагал в первом посте (а может в последующем), вот там и присутствует избыточность.
И так ли себя оправдает динамический запрос, как ты его  представляешь?
а идея Hadkotа вполне приемлема.
И почему ты считаешь, что в справочнике будет много записей? Много - это сколько?

[Dimka]

Справочники создаются по крайней мере по двум причинам:

1) нормализация (когда значения, хранящиеся в справочнике, включены в несколько отношений);

2) аномалии (данные текстовых или двоичных типов не должны повторяться, если используются в качестве ключей поиска или имеют более узкие домены, нежели типы этих данных). Там, где пользователь может сделать опечатки и получить расхождение по форме данных, имеющих одну суть. Там, где в пользовательском интерфейсе имеются combo-box или list для выбора одного или нескольких значений из ограниченного набора (но иногда не обязательно).

[nikedeforest]

Ответ на пост SLA.

справочник это статические таблицы (один раз создал и забыл)

Разве статические??? Вроде как, за время жизни БД справочник изменяеться (по крайней мере записей в нем прибавляються), я не исключаю статические справочники, но насколько я знаю, справочники бывают динамическими. Если я не прав, поправьте.

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

я не спорю, но я чего-то не разглядел. Как dimka не старался мне объяснить и нф припомнил, я с ним в принципе согласен, но почему-то мне понравилась моя идея и теперь пытаюсь избавиться от неё. Честно сказать, я не обращался к НФ когда решил делать, тот 4ех столбцовый справочник, а руководствовался чисто интуитвными доводами.

И так ли себя оправдает динамический запрос, как ты его  представляешь?

НЕ ЗНАЮ. Я же писал, что при динамические запросы узнал недавно и поработать мне с ними не пришлось еще. Я не работал с ними, не знаю в каких случаях их следует применять, а в каких нет.
Вот вопрос кстати: динамические запросы используються вне хранимых процедур??? (Пример, если можно и синтаксический и смысловой).

а идея Hadkotа вполне приемлема.

Я ее не сразу догнал, меня смутили повторения в поле pn.Пока Я эту идею не выбрасываю из рассмотрения.

Много - это сколько?

здесь теория относительности . Много-больше чем ранее .

[nikedeforest]

dimka, понял, точнее перевариваю.

[Sla]

Когда я говорил про статические, я подразумевал - редко меняющиеся (ты часто меняешь словари?)
Пример динамического запроса можно конечно привести, но он на plsql, тебе оно надо?

Много - это когда сложно сказать сколько
В словаре Эллочки -35 слов (это много?)
В словаре Пушкина - 3500 слов (это много?)
В русском словаре - ну пусть будет 35000 слов (это много?)

а в твоем случае - немного, по крайней мере, их можно перечислить

[Dimka]

Пример аномалии.

Пусть есть отношение, где неключевым атрибутом является улица (как текст). Пусть "Московская" повторяется много раз. Пользователь вводит название вручную. Один из юзеров сделал опечатку "Масковская", система внесла в таблицу. Получаем 2 разных по форме улицы, но логически относящиеся к одному объекту реального мира. Ищем данные по улице "Московская" - будут пропущены все с опечатками. Практика показывает, что улицы с названиями длиной около 8 букв в таблицах с несколькими тысячами записей могут иметь до 25 разночтений, что приводит БД в неработоспосбное состояние (толку от такой БД нет, работать с ней невозможно).

Как проблема решается. Создаётся справочник улиц, где написание улицы "Московская" однозначно. Ключами являются числа. Пользователю предоставляется combo-box со списком улиц вместо text-box, где он ранее набивал название, и в меню выносится ссылка на отдельный справочник улиц: открывается список улиц со стандартными функциями добавления новой, редактирования имеющейся, удаления старой.

В случае переименования улицы достаточно изменить 1 запись справочника, вместо того чтобы прочёсывать всю базу данных в поисках названия этой улицы.

[HandKot]

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

2 dimka идея действительно неудачная и сразу было понятно, что надо делать кучу справочников. Я просто предложил примерное решение под поставленную задачу не меняя кардинально исходных данных (замену одной таблиц  4 ) и для облегчения написания запросов в ХП с чего в принципе все и началось...