Здравствуйте всем!

DB2 8.2

Хочу поднять вопрос в общем плане. Ранее при разработке структуры БД не задумывался как у меня будут связаны справочники и рабочие данные. Делал классически - в таблице справочника есть NSI_ID (Primary), в рабочей таблице также есть NSI_ID (Foreign), по которым устанавливал связь. Но в этом способе при взгляде только на рабочую таблицу она выглядит непрозрачно - мы не видим, что скрывается за NSI_ID, пока не выполним join.

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

С уважением, Семен Попов

const64, спасибо. Посмотрю книжку. Но вот если разобрать по полочкам. Я представляю, что таблица справочника должна иметь:
1. ID для связи с другими таблицами
2. COD (уникальный) для удобства выбора записи справочника, ведь пользователь может не осуществлять выбор из списка, а может ввести её код
3. поле(я), несущие информативную часть, например Наименование, Адрес и т.п.
4.(может и не быть, зависит от технологии) поля, влияющие на логику ввода и хранение рабочих данных,

Если делаю увязку по ID, то изменение полей 2 и 3 никак не нарушит целостность и логику хранения рабочих данных, но вот изменение 4 полностью нарушит логику уже внесенных данных. Как бы увязать, чтобы при изменении 4 не было проблем? В принципе, можно 4 жестко привязать по смыслу к коду и связь между таблицами выполнить по полю COD, например считать, что код=100 - это запись с такой-то логикой, а код=101 - запись с другой логикой. Или не позволять изменять 4?

Приведу пример по-конкретнее.

Есть справочник "Типовые ошибки документов" NSIERR:
ERRID,
COD (код ошибки для удобства пользователя),
NAM (наименование ошибки),
ISOTHER (признак "Прочие ошибки").

Есть рабочая таблица документов WRKDOC:
WDID,
{поля, описывающие документ}.

Есть рабочая таблица ошибок документа WDERR:
WDEID, WDID (для связи с WRKDOC), ERRID (выбранная ошибка из справочника).

Есть рабочая таблица пояснений к прочим ошибкам документа WDERRNOTE:
WDENID,
WDEID (для связи с WDERR),
NOTE (пояснение).

Пояснение к ошибкам по технологии можно вводить только для ошибок с признаком "Прочие", поэтому на уровне приложения отслеживаю, если выбрана ошибка с ISOTHER=1, то позволяю вносить пояснения. Ну и на уровне базы просматривается некоторая логика - для конкретных видов ошибок есть пояснения. Но как организовать связь между справочником и рабочими таблицами или изменить подход к структуре БД, чтобы при изменении ISOTHER=0 не оставались "висячие" записи WDOTERR?

const64В принципе, структура у Вас нормальная, только поле ERRID - лишнее, связывайте по COD.
И по основному вопросу - зачем Вы смотрите таблицы, создайте view.Связка по ERRID была бы полезна в том случае, если по истечении какого-то времени пользователю захочется изменить код ошибки в справочнике и при этом не потерять увязку на ошибку. Например, им стало неудобно, что некоторая ошибка вводится под номером 5. Они захотели 25, а код 5 присвоить другой ошибке. Или вдруг это потребует технология работы. В структуре с ERRID проще изменить код записи. Коды записей справочника в моей логике, как я уже говорил, нужны только для удобства ввода пользователем. Ему проще помнить и ввести код записи, чем листать справочник.

По основному вопросу. Прозрачность я имел ввиду с точки зрения самой же таблицы. Например, в рабочей таблице есть поле NOTE, которое согласно технологие может быть заполнено только, если ISOTHER=1. Как на уровне БД в рабочей таблице заложить проверку этого дела, если она "знает" только ни о чем не говорящее ERRID?
Как решение, можно уйти от ERRID и ISOTHER и связываться по ERRCOD и считать, что в справочнике для записей с признаком "Прочее" выделен определенный интервал кодов. Например, если следовать логике, что записи с признаком "Прочее" могут иметь код только 99 и 100. Тогда бы в рабочей таблице можно было какой-нибудь констрайнт навесить на проверку кода ERRCOD и исходя из его значения заполненность поля NOTE. Но тут минус - коды справочника будут зарезевированы и пользователь не сможет их менять. Это маленький пример. Логика может быть такая, что от признака "Прочее" у записи из справочника может зависеть и многое другое. А если делать связку по ID, то одним взмахом руки (изменением состояния признака "Прочее" в справочнике) мы можем перечеркнуть всю логику хранения рабочих данных.

const64Вы же в приложении можете реализовать заполнение табл. WDERRNOTE только для ошибок ISOTHER=1? А если пользователь меняет значение в этом поле - повесьте триггер на update который Вам удалит соотв. записи из табл. WDERRNOTE.Могу. В форме добавления в зависимости от выбранной записи справочника это не составляет труда. Проблема будет, если в справочнике пользователь изменит признак, когда в рабочих таблицах уже есть данные, ссылающиеся на эту запись справочника. Тут наверно, действительно, только триггер поможет. А если логика уж слишком сложна, то вообще не позволять изменять этот признак, пока есть соответствующие рабочие данные. Пусть сначала ручками изменят все рабочие данные на другую логику или вообще удалят, а затем уже позволить изменить справочник. А можно ли в триггере before отменить текущую операцию (удаления или изменения)?

const64И, кстати, я бы еще подумал - м.б. стоит добавить поле NOTE в WDERR, а WDERRNOTE вообще извести? Но это будет рентабельно если: событий не очень много или большинство являются "прочими ошибками" и если поле NOTE не слишком большоеСпасибо. Я подумаю.

const64Вы же в приложении можете реализовать заполнение табл. WDERRNOTE только для ошибок ISOTHER=1?И ещё. Хотелось бы, чтобы БД сама отслеживала и не допускала добавление записей в WDERRNOTE, если ISOTHER=0. Наверно, это тоже только триггером отслеживать.