Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
Как лучше организовать правила целостности
|
|||
|---|---|---|---|
|
#18+
Немного о себе... Наша БД организована следующим образом. Таблица, на нее навешены несколько триггеров, из этих триггеров вызываются функции пакета, написанного специально для этой таблицы. И так для всех 500 таблиц. Все однотипно. В пакете проверяются все ограничения, правила целостности, кое-где реализована бизнес-логика. Все это создается через ErWin, и вроде работает. Теперь сама проблема. Организация наша довольно старая. на Oracle переходим только-только, раньше все с DBF. Довольно часто постановщики удаляют таблицы напрямую через TOAD. Соответственно летят напрочь все связанные пакеты. Можно конечно запретить такое делать, но это такой геморрой и столько нервов. Да к тому же не всегда помогает. Ведь если в ErWinе меняешь таблицу, то надо генерировать и все пакеты связанных таблиц. Пока в голову пришли две мысли, создать скрипты для генерации, удаления, и тому подобное для схемы, но тогда зачем мне ErWin? Вторая мысль - все ограничения зашить в какую-нибудь таблицу, нечто вроде user_constraints, и из "табличного" пакета находить и применять эти ограничения. И обе эти мысли мне не нравятся. Но делать что-то надо. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.07.2004, 12:14 |
|
||
|
Как лучше организовать правила целостности
|
|||
|---|---|---|---|
|
#18+
<Но делать что-то надо>. создавать движение какое то - мать его 1 Уровень данные (ORACLE) : см ---> create table DEAL_LIST0303 --типы для словаря терминов ( RN number(17), CODE varchar2(20), NAME varchar2(160) ) tablespace TOOLS storage (.... ); alter table DEAL_LIST0303 ---> add constraint C_DEAL_LIST0303_PK primary key (RN) using index tablespace INDX pctfree 10 initrans 2 maxtrans 255 storage (...); ---> alter table DEAL_LIST0303 add constraint C_DEAL_LIST0303_CODE_UK unique (CODE) using index tablespace INDX pctfree 10 initrans 2 maxtrans 255 storage ( initial 128K next 128K minextents 1 maxextents unlimited pctincrease alter table DEAL_LIST0303 add constraint C_DEAL_LIST0303_CODE_IN check (CODE in( 'RUR','USD','CAD','FRN' )); create table DEAL_LIST0301 --словарь для разделов ( RN number(17), COUNTER number(17), TYPE number(17), NAME varchar2(160) ) tablespace TOOLS storage ( initial 128K next 128K minextents 1 maxextents unlimited pctincrease 0 ); alter table DEAL_LIST0301 ---> add constraint C_DEAL_LIST0301_PK primary key (RN) using index tablespace INDX pctfree 10 initrans 2 maxtrans 255 storage (...); ---> alter table DEAL_LIST0301 add constraint C_DEAL_LIST0301_COUNTER_UK unique (COUNTER) using index tablespace INDX pctfree 10 initrans 2 maxtrans 255 storage ( initial 128K next 128K minextents 1 maxextents unlimited pctincrease 0 ); ---> alter table DEAL_LIST0301 add constraint C_DEAL_LIST0301_TYPE_FK foreign key (TYPE) references DEAL_LIST0303 (RN) on delete cascade; 2 Уровень - в пакетах бизнес логика 3 Уровень - в клиентских формах валидация вводимых значений Правда структура получтися жесткая, но надежная ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.07.2004, 12:48 |
|
||
|
Как лучше организовать правила целостности
|
|||
|---|---|---|---|
|
#18+
Я Ервином так пользоватся и не научился, поэтому делаю все через свои скрипты. Если структура таблиц однотипная, как у меня, типа документ_шапка - документ_детали и связанные с ними референсы, процедуры и триггеры, имеет смысл сделать шаблон сущности "документ", и заскриптовать его. Придобавлении нового документа элементарными функциями в скрипт подставляются имена нового документа, при удалении - удаляется все, что связано с этим документом таким же макаром, по именам. Вот и все. Есть правда еще многофункциональные процедуры, для сводных отчетов, где от типа документа зависит, какие данные нужно выдать, там я стройной системы не придумал, в них придется ручками добавлять-удалять. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.07.2004, 07:56 |
|
||
|
Как лучше организовать правила целостности
|
|||
|---|---|---|---|
|
#18+
2vkorytko Что-то не понял... 2TimKa А у нас все сделано через ErWin В результате получается пакеты, в которых и написано нечто вроде Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. Ну и соответственно если много связей, то получается читаемый, но громоздкий пакет. Хотелось обойти это дело, создав нечто вроде своей метамодели, только вот стоит ли? Или же списать все это на издержки переходного периода и ужесточить административные требования? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.07.2004, 14:26 |
|
||
|
Как лучше организовать правила целостности
|
|||
|---|---|---|---|
|
#18+
2 Тимка Если структура таблиц однотипная, как у меня, типа документ_шапка - документ_детали и связанные с ними референсы, процедуры и триггеры, имеет смысл сделать шаблон сущности "документ", и заскриптовать его. Придобавлении нового документа элементарными функциями в скрипт подставляются имена нового документа, при удалении - удаляется все, что связано с этим документом таким же макаром, по именам. Еще расскажи, с примером, если не трудно. Не въехал. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.07.2004, 15:05 |
|
||
|
Как лучше организовать правила целостности
|
|||
|---|---|---|---|
|
#18+
to donkey - этот лисапед уже изобретен и штатно прошит разработчиками баз данных (ORACLE,MS,Borland) Я привел в качестве примера использование штатных ограничений ссылочной целосности и проверок отношения и валидность в таблицах (1 уровень) 2 уровень - собственно часть логики бизнес-процесса - (напр. отрицательное количество - в таблице допускается - а на складе(по факту) - нет. 3 уровень - собственно пользовательский - (пока не заполнены первыe 4 и 5 поля к нопка OK неактивная- и (или) 6-е поле правильно заполняется только из справочника (там 10 000 значений ) ) Понятнее ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.07.2004, 16:08 |
|
||
|
Как лучше организовать правила целостности
|
|||
|---|---|---|---|
|
#18+
1) бить тех, кто удаляет напрямую по наглой рыжей морде. 2) Изменение структуру только через ервин. Желательно - одним человеком, который приставлен следить за структурой. 3) Всё-таки целостность предоставить по возможности блюсти базе самой. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.07.2004, 16:29 |
|
||
|
Как лучше организовать правила целостности
|
|||
|---|---|---|---|
|
#18+
2 vkorytko Стыдно признаться, но непонятно. Основы реляционных баз я знаю... 2 All Этой самой нашей разработке года три. Как-то так получилось, что частично она уже внедрена, частично доводится до ума, частично еще не начата. (Это я про базу данных). То есть уже написана куча программ, гда работа с БД идет напрямую, не через ХП, и переписывать их... Павел Воронцов 3) Всё-таки целостность предоставить по возможности блюсти базе самой. Я и сам так думаю, но вот тогда ошибки пойдут ораклевые, а у нас в пакетах текст ошибок генерируется из логической модели ErWin. Потом, есть постановщики, которые имеют смутное представление о нормальных формах. Например, недавно только видел таблицу, где полей 30 ссылались на одно поле из другой таблицы. В пакете получилось 30 проверок. Есть и другие извраты. Например, при загрузке таблиц из DBF-файлов требуется отключать некоторые ограничения. Было бы сделано по стандарту, отключил бы констрайнт и все. Сейчас же надо лезть или в пакет, там править, или же вырубать триггера. Вот я и подумал, что или сделать еще одну таблицу, где мною будут описаны все ограничания, связи между таблицами, статус их(DISABLE, ENABLE). Или же такую таблицу создавать в пакете, как коллекцию. Вот только бы такими переделками не тормознуть бы базу напрочь. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.07.2004, 07:41 |
|
||
|
Как лучше организовать правила целостности
|
|||
|---|---|---|---|
|
#18+
donkeyЯ и сам так думаю, но вот тогда ошибки пойдут ораклевые, а у нас в пакетах текст ошибок генерируется из логической модели ErWin. Одно другому не мешает. В пакетах ловите EXCEPTION и кидайте вожделенную ошибку с каким угодно текстом. Автоматизируется на ура. donkey Потом, есть постановщики, которые имеют смутное представление о нормальных формах. Убивать на месте. Заведите одного (или сколько нужно) постановщиков, которые разбираются и следят за правильностью базы. Всех остальных с их хотелками отсылать к этим людям. Иначе будет дурдом и зоопарк (которого и так у вас хватает по всей видимости) donkeyНапример, недавно только видел таблицу, где полей 30 ссылались на одно поле из другой таблицы. В пакете получилось 30 проверок. Есть и другие извраты. Например, при загрузке таблиц из DBF-файлов требуется отключать некоторые ограничения. Было бы сделано по стандарту, отключил бы констрайнт и все. Сейчас же надо лезть или в пакет, там править, или же вырубать триггера. Вот я и подумал, что или сделать еще одну таблицу, где мною будут описаны все ограничания, связи между таблицами, статус их(DISABLE, ENABLE). Или же такую таблицу создавать в пакете, как коллекцию. Вот только бы такими переделками не тормознуть бы базу напрочь. Лучше наверно всё же сперва подготовить данные для загрузки чтобы они не вызывали конфликтов в базе, а потом уже грузить? Подготавливать можно и в самой базе в отдельном месте, которое после успешной операции чистить нафиг. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.07.2004, 09:28 |
|
||
|
Как лучше организовать правила целостности
|
|||
|---|---|---|---|
|
#18+
Павел Воронцов Вот у нас как бы все так делается, но не всегда. Вот, еще один изврат - отказ от суррогатного ключа с переходом на составной Может и правильно, но аргументация была такова - суррогатный ключ может иметь значения 1, 2, 123, 5000, ... что очень некрасиво. Но это ладно. А вот если не использовать возможности Oracle, то стоит ли заморачиваться с созданием своей таблицы, где описаны ограничения? Вот у нас сейчас в пакетах реализованы каскадное удаление, обновление. С одной стороны опасное дело, а с другой программерам не надо мотаться по всем связям, тем более им их неоткуда взять. Честно говоря, охота мне сделать таблицу метаданных, но где-то лень, да и страшновато. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.07.2004, 09:56 |
|
||
|
Как лучше организовать правила целостности
|
|||
|---|---|---|---|
|
#18+
mv Еще расскажи, с примером, если не трудно. Не въехал. Пример - заводишь таблицу ___TPL_H и ___TPL_DET, в которых есть обязательные для всех таблиц одного типа поля - ключи, коментарии, информация о том кто вводил и когда, даты, номера документов итп. Связываешь их, расставляешь правила целостности и индексы, какие надо, триггеры. Строишь хранимые процедуры, какие надо, типа добавить документ, провести, и так далее. Проверяешь как все это работает, конечно отлаживаешь до тех пор пока не понравится. Генеришь скрипт - в SQL SERVER это делается просто, в других не знаю, в него включены скрипты на создание таблиц индексов и. Теперь, если надо добавить новый документ, в скриптах, спец процедурой, ессно, заменяешь строку "__TPL" на имена документов и исполняешь их - и у тебя готова заготовка для документа со всеми прецедурами триггерами и функциями, относящимися к нему. Далее добавляешь все поля, связи, процедуры и функции, которые характерны только для этого вида документа. Теперь если надо удалить документ, запускаешь другой скрипт, который удаляет всю эту армаду скопом так же по имени. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.07.2004, 10:45 |
|
||
|
Как лучше организовать правила целостности
|
|||
|---|---|---|---|
|
#18+
To donkey Зачем городить свои таблицы метаданных если они уже есть в базе и поддерживаются самим сервером? Зачем?! Кстати - схема в ЕрВине тоже является хранилищем метаданных. И дублировать её в самом сервере никакого смысла нет - вы получите дополнительный геморрой с синхронизацией этих друх хранилищ. Оно вам нужно? А суррогатные ключи - это костыль и если вы умеете ходить без него, то это очень хорошо. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.07.2004, 11:38 |
|
||
|
Как лучше организовать правила целостности
|
|||
|---|---|---|---|
|
#18+
2 Павел Воронцов Схема ErWin и рабочая схема у нас в разных базах, да и предприятий несколько. Хотя я позабыл, когда-то у нас создавалась метамодель из ErWin, просто давно уже не пользуемся. Все вопросы мои относятся к тому случаю, когда мы отказываемя от реализации ограничений через возможности Oracle и реализуем их в пакетах. Выше я писал, что просто "взять и поделить" не получится. Вот например, каскадное обновление через constraint ведь не сделаешь? Через ХП мы не работаем, а программы, которые использует каскадное обновление через наши пакеты, есть. В общем у меня остался неясным только один вопрос, оставить ли пакеты в прежнем состоянии, где подряд идут множество проверок, или же написать несколько функций, которые, обращаясь к метамодели, сгенерированной из ErWin, выдернут ограничения для текущей таблицы и выполнят их. Возможно, это будет несколько медленне, но зато можно будет отключать, включать ограничения по мере необходимости. Еще раз повторяюсь, все это на тот случай, когда не используются стандартные возможности СУБД Oracle. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.07.2004, 12:06 |
|
||
|
Как лучше организовать правила целостности
|
|||
|---|---|---|---|
|
#18+
Ну вы блин даёте.. Код: plaintext 1. 2. 3. 4. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.07.2004, 12:17 |
|
||
|
Как лучше организовать правила целостности
|
|||
|---|---|---|---|
|
#18+
Я же пишу про UPDATE CASCADE? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.07.2004, 12:33 |
|
||
|
Как лучше организовать правила целостности
|
|||
|---|---|---|---|
|
#18+
пардон, зарапортовался Делаете FK DEFERRABLE и производите апдейт детей в BEFORE UPDATE триггере. Вот вам и UPDATE CASCADE.... Хотя конечно можно и оставить всё как есть - тоже вариант. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.07.2004, 13:20 |
|
||
|
Как лучше организовать правила целостности
|
|||
|---|---|---|---|
|
#18+
Всем спасибо, поговорил, хоть немного структуризовался. Есть некоторые неясности, но это видно только через эксперименты. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.07.2004, 13:32 |
|
||
|
Как лучше организовать правила целостности
|
|||
|---|---|---|---|
|
#18+
Павел ВоронцовА суррогатные ключи - это костыль и если вы умеете ходить без него, то это очень хорошо. LOL. Мне казалось что "естественники" вымерли еще лет пять назад во времена "религиозных войн искуственников против естественников". Естественные ключи против искуственных ключей Однако ж живы еще еретики-то! Правильно ли генерировать Primary Key на основе Sequence Суррогатные или естественные Суррогатные или естественные ключи в ERP-системах и далее до посинения... Я бы сказал не "костыль", а инструмент. Не умеете - не пользуйтесь ;-) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.07.2004, 13:45 |
|
||
|
Как лучше организовать правила целостности
|
|||
|---|---|---|---|
|
#18+
Ну что Вы, совсем нет, живут, и процветают по-своему! Недавно вот видел, один уважаемый мною специалист ваял проект в ErWin, так вот - все связи - т.н. "Индентифицирующие", и все клоючи - "Естественные". Т.К. "естественные" не всегда уникальны, введена спец. процедура проверки и коррекции - в ключ добавлено поле "Variant" - в котором дополнительно вписывается вариант. FIO = "Иванов Иван Иванович", Variant = 1. Представляете - связи 1-Many с большой степенью вложенности? И все у него годами работает, отлажено и налажено. У меня долго глаза были большими и круглыми. А может, он прав, а мы дураки? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.07.2004, 13:56 |
|
||
|
|

start [/forum/topic.php?fid=32&fpage=165&tid=1546337]: |
0ms |
get settings: |
6ms |
get forum list: |
16ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
28ms |
get topic data: |
9ms |
get forum data: |
2ms |
get page messages: |
50ms |
get tp. blocked users: |
1ms |
| others: | 224ms |
| total: | 342ms |

| 0 / 0 |
