Гость
Войти | Профиль | Очистить
Целевая тема:
Создать новую тему:
Автор:
Действия ...
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / Ссылочная целостность / 25 сообщений из 42, страница 1 из 2
  1  все
16.07.2004, 11:37
    #32607646
Ggg_old
Ggg_old
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Ссылочная целостность
В дискуссиях этого топика часто проскакивает тезис, что в "правильной" БД должны обязательно использоваться констрэйнты. Все БД, с которыми мне приходилось видеть не использовали констрэйнты, но работа с объектами БД была допустима только через ХП. Собственно я в своих БД я использую этот принцип - работа только через ХП, констрэйнты не используются (ну разве на этапе разработки БД, потом отключаю). Универсального правила естественно нет, особенно если едет речь о нагруженной OLTP системе.
Хочется услышать ваше мнение.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
16.07.2004, 11:52
    #32607704
Сергей Васкецов
Сергей Васкецов
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Ссылочная целостность
Ggg_oldособенно если едет речь о нагруженной OLTP системе.
Хочется услышать ваше мнение.
Даже реализация ссылочной целостности на триггерах подчас быстрее будет в OLTP. Чего уж говорить про SP.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
16.07.2004, 12:00
    #32607729
optimizer
optimizer
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Ссылочная целостность
Надежно и правилно будет использование ограничений. Это последняя линия обороны. Во всех программных проектах, особенно больших, имеется допущение, что в коде существует ошибка. Использование ограничений в СУБД даст возможнось увеличить надежность ("правильность"). А если это касается ссылочной целостности (и не только), то она логическим образом вытекает (чаще всего) прямо из ER - модели
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
16.07.2004, 12:25
    #32607807
Станислав C.
Станислав C.
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Ссылочная целостность
Ggg_oldХочется услышать ваше мнение.
Мое мнение, основанное правда, лишь на теоретических знаниях по SQL-Server (сам я все еще работаю в ДОСе :-( ) и хранилищам данных, сводится к тому, что в правильно разработанной OLTP-системе (все таблицы находятся минимум в 3НФ или НФБК) не должно быть "ручных" (или через хранимые процедуры) проверок ссылочной целостности.
Ggg_oldУниверсального правила естественно нет, особенно если едет речь о нагруженной OLTP системе.
А по-моему, есть. Для любой OLTP-системы (хоть нагруженной, хоть нет).
И это - автоматический контроль ссылочной целостности при помощи СУБД. Для чего строить индексы, первичные и внешние ключи, связи и т.д., если затем все заново самому проверять! Не дело OLTP-систем проводить аналитическую работу. Они нужны лишь как накопители оперативных данных о заказах, продажах, покупках и т.д. за небольшой промежуток времени (день, неделя, месяц, максимум - год). Данные в них - динамически меняются. Порой по нескольку раз за день. Отследить же все возможные "подводные камни" в силах только СУБД с ее автоматическим контролем целостности.

А вот в OLAP-системах и хранилищах данных, где хранятся данные за несколько лет или десяток лет, и данные эти изменяются (дописываются) в лучшем случае раз в день (а то и значительно реже), на самом деле лучше отказаться от автоматического контроля целостности. По заявлениям Кодда (являющегося также родоначальником OLAP) объем данных OLAP-системы из-за различных видов группировок и суммирования в 2,5 - 100 раз больше, чем в OLTP-системе...
Но там несколько иная ситуация - частичная денормализация таблиц (приводящая к появлению дублирующихся записей) ради ускорения (и упрощения) SQL-запросов, различные заморочки с представлением данных из OLTP-систем в виде OLAP-кубов и т.д. А это уже совсем другая история...
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
16.07.2004, 13:00
    #32607930
Ggg_old
Ggg_old
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Ссылочная целостность
Ggg_old:
Использование констрэйнтов это хорошо и правильно. Я говорю о компромисе, который нужен для обеспечения скорости и уменьшения потребления ресурсов. Отсутствие прямого доступа в БД и работа через ХП это позволяют достичь, т.к. частенько в ХП делать проверки приходится все равно. ТОлько в ХП я могу выбирать что делать, а что нет, гибко отследить ошибку, принять решение о ее устранении и.т.д. Хотя, если БД разрабатывается не очень добросовестно, или очень много людей имеют доступ девелопера,не имея нужной квалификации, то ХП - это последний барьер.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
16.07.2004, 13:02
    #32607940
Ggg_old
Ggg_old
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Ссылочная целостность
опечатка :(
читать надо
"...то констрэйнты - это последний барьер..."
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
16.07.2004, 15:27
    #32608445
*
*
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Ссылочная целостность
Было бы интересно узнать, как с помощью программного кода реализовать проверку уникальности и корректности ссылки. Особенно интересно как это сделать в Oracle
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
21.07.2004, 12:05
    #32614351
TimKa
TimKa
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Ссылочная целостность
/topic/103173

вот здесь в частности про это копья ломали.

Я себе взял за правило обеспечивать как ссылочную целостность, так и ограничения на значения все-таки средствами СУБД а не кодом триггеров и ХП, в котором

1. Могут быть ошибки
2. Может быть не оптимизирован.
3. Не столь явно диктуется бизнес правилами.
4. Может даже быть плохо переносим.
5. Не ясен для понимания людям из поддержки.

Насчет скорости я тоже сильносомневаюсь, что быстрее, по крайней мере на WEB нашел две рекомендации реализовать целостность декларативно ссылками и ни одной обратной рекомендации.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
22.07.2004, 10:13
    #32616210
bokarev
bokarev
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Ссылочная целостность
а нафига тогда БД если не использовать то что она предоставляет,
зачем программировать то что уже реализовано в механизме БД.
потом при создании констраинтов создаются и соответствующие индексы.
Просто часто встречаются программисты не доверяющие никому,
они считают что правильно работает только то что они сами написали.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
22.07.2004, 12:39
    #32616688
Denis Popov
Denis Popov
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Ссылочная целостность
Сам код проверки "правильности" данных может быть основан на обработке исключений, возникающих при существовании ограничений целостности. Для Oracle:

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
create table master (
    master_id number( 9 )
  , constraint pk_master primary key (master_id)
);
create table detail (
    detail_id number( 9 )
  , master_id number( 9 )
  , constraint pk_detail primary key (detail_id)
  , constraint fk_detail_master foreign key (master_id) references master(master_id)
);

insert into master (master_id) values ( 1 );
commit;

declare
  parent_not_found exception;
  pragma exception_init(parent_not_found, - 2291 );
  child_record_found exception;
  pragma exception_init(child_record_found, - 2292 );
begin
  begin
    insert into detail (detail_id, master_id) values ( 1 ,  0 );
  exception when parent_not_found then
     -- Обработка исключения.
 

    null;
  end;
  insert into detail (detail_id, master_id) values ( 1 ,  1 );
  begin
    delete master where master_id =  1 ;
  exception when child_record_found then
     -- Обработка исключения.
 

    null;
  end;
end;
/

Соответственно, если в дальнейшем ограничения целостности будут убраны, то код будет работать несколько по-иному. Даже если административно запретить именно такой способ написания кода, то может сложиться ситуация, когда впоследствии будет разрабатываться новый код программистами, которым это ограничение по каким-то причинам было неизвестно.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
22.07.2004, 16:58
    #32617464
Сергей Васкецов
Сергей Васкецов
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Ссылочная целостность
bokarevпотом при создании констраинтов создаются и соответствующие индексы
Что это за бред?! Где это реализовано для Constraint не Primary key?
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
22.07.2004, 18:03
    #32617628
ChA
ChA
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Ссылочная целостность
Например - UNIQUE
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
22.07.2004, 19:40
    #32617750
Сергей Васкецов
Сергей Васкецов
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Ссылочная целостность
Что UNIQUE?
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
23.07.2004, 01:45
    #32617885
ChA
ChA
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Ссылочная целостность
Ограничение UNIQUE тоже создает индех. По крайней мере в MS SQL...
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
23.07.2004, 10:01
    #32618078
bokarev
bokarev
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Ссылочная целостность
Что это за бред?! Где это реализовано для Constraint не Primary key?[/quot]

RBO в Oracle работает используя FK и PK и соответствующие индексы, и я так и не понял что вы называете бредом ?
обоснуйте пожалуйста.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
23.07.2004, 11:04
    #32618247
Kassandra
Kassandra
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Ссылочная целостность
Констрейнты - это святое в теории БД.
Подумайте о тех, кто придет после Вас и будет писать Приложения к Вашей БД. Я им не завидую.
А автоматическое (то бишь при создании констрейнта) создание индексов реализовано, например, в Interbase, Paradox etc.
wbr, k
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
23.07.2004, 11:37
    #32618349
TimKa
TimKa
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Ссылочная целостность
Подумайте о тех, кто придет после Вас и будет писать Приложения к Вашей БД. Я им не завидую.

Есть мнение
"А нафига о ламаках думать - не разберутся в нашем крутом коде - их проблемы, у нас-то все работало, когда сдавали."
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
23.07.2004, 12:22
    #32618504
Kassandra
Kassandra
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Ссылочная целостность
Нет, ну если "после нас хоть потоп", тогда ты верной дорогой идешь :)

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

Сколько таблиц было в тех БД, которые тебе приходилось видеть?
Сколько таблиц в твоих в БД? Если пара-тройка, тогда твой вопрос может, и имеет смысл.
А, вообще, есть бизнес-правила (в частности, констрэйнты) - это как бы врожденное :)
А есть прикладной код на сервере/клиенте, который заведует функциональностью: сегодня такой, завтра сякой.
Отними сейчас твой код, и вместо БД получится просто набор таблиц - Куча
Поэтому имхо лучше, все-таки, отделять мух от котлет.
А какие доводы против констрэйнтов?
Ggg_oldно работа с объектами БД была допустима только через ХП. Собственно я в своих БД я использую этот принцип - работа только через ХП,
И что хорошего в этом ограничении?
wbr, k
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
23.07.2004, 12:54
    #32618590
Сергей Васкецов
Сергей Васкецов
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Ссылочная целостность
bokarevиспользуя FK и PK и соответствующие индексы, и я так и не понял что вы называете бредом ?
В общем случае это не так. Только для PK гарантировано должен создаваться индекс, все остальное нивелирует разницу между UNIQUE INDEX и UNIQUE CONSTRAINT и является ошибкой разработчиков многих серверов БД (точнее, большинства, потому что так легче).

Вот, например, скрипт для MSSQL:

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
create table xxx
(id numeric( 16 , 0 ) identity,
 code int not null,
 descript varchar( 255 ) null,
 constraint PK_xxx primary key clustered (id))
go

alter table xxx
add constraint UK_xxx unique (code)
go

alter table xxx
add parent_id numeric( 16 , 0 ) null references xxx
go

select *
 from sysindexes
 where id = object_id('xxx')
go

последний запрос возвращает PK_xxx и UK_xxx. То есть, для FK индекс НЕ СОЗДАЛСЯ, что правильно, ибо нафиг он не нужен по умолчанию (если в Oracle это не так - мне искренне жаль). Но зачем создается индекс UK_xxx - не понятно, в общем случае в нем может не быть необходимости (опять же, проще всего вообще внутри сервера не разделять UK и UI, что в большинстве серверов имеет место, за исключением статистики по UI).
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
23.07.2004, 13:24
    #32618676
bokarev
bokarev
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Ссылочная целостность
c FK нет индексов - согласен.
я сейчас как раз сижу на базе в которой нет ссылочной целостности,
и скажу это очень не весело. Это как раз тот случай когда многа кода,
большая база (>1000 таблиц) и приложению уже больше 15 лет.
сейчас в эту базу ввести ссылочную целостность очень сложно(может вообще невозможно), а втыки с дублирующимсяи и висящими записями встречаются постоянно
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
23.07.2004, 13:46
    #32618744
Ggg_old
Ggg_old
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Ссылочная целостность
2kassandra:
БД - опердень банка. Таблиц - сотни, процедур - аналогично. Есть основные таблицы (например таблица платежей и остатков), есть куча справочников (например коды банков, коды операций, исполнителей и.т.п). В таблице платежей - за все время записей около 20 млн. Констрэйнты не используются. При операции ввода или проведения нового платежа все проверки по любому делаются только в соответствующей ХП. Как бы работала система по скорости, если бы на таблицу платежей еще бы был констрэйнт практически на все ее поля я не знаю - но предполагаю, что-бы тормоз был конретный, хотя я не имел опыта работы с большими БД с интенсивной нагрузкой аналогичной нашей. БД разрабатывается выделенными разработчиками, естественно уровень отвественности и исполнения очень высокий. Имея в качестве примера "большую" БД, свои мелкие БД (действительно пара-тройка таблиц и десяток-другой процедур)я делаю по такому-же принципу. Единственно, что при процедуроориентированной работе БД, я стараюсь делить ХП на несколько как-бы уровней (интерфейсные ХП, - которые вызываются пользователями и ХП уровня "ядра" - которых гораздо меньше и только через них ведется манипулирование свойствами объектов БД. В целом - принцип работающий.
Но я еще раз повторяюсь - я за констрэйнты, но между теорией и практикой всегда есть разрыв. Хочется услышать аргументы за частичный или полный отказ от констрэйнтов в БД и когда это оправдано.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
23.07.2004, 13:53
    #32618765
ChA
ChA
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Ссылочная целостность
Сергей ВаскецовТолько для PK гарантировано должен создаваться индекс
Это где-то в теории РБД протоколируется ? Ссылку, если можно... Насколько
я понимаю, ограничения относятся к теории, а их реализация к практике.
Ни в одной книге по теории БД я не встречал такого сильного утверждения,
теория вообще не знает ничего об индексах.
Создание уникальных индексов для PRIMARY и UNIQUE, как Вы правильно
заметили, выполняется именно для простоты, так как иначе для поддержки
соответствующих ограничений пришлось бы сканировать всю таблицу.
Ограничение UNIQUE является потенциальным или альтернативным ключом
и в некотором смысле аналогичным PRIMARY.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
23.07.2004, 13:57
    #32618776
*
*
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Ссылочная целостность
В ORACLE для UK индекс создается, для FK нет.
Если бы не создавался, как проверить уникальность?
Для проверки корректности FK индекс не нужен,
НО попытка удалить запись в главной таблице приводит
к неприятносттям если в подчиненной нет подходящего индекса
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
23.07.2004, 14:18
    #32618856
Сергей Васкецов
Сергей Васкецов
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Ссылочная целостность
ChAНи в одной книге по теории БД я не встречал такого сильного утверждения, теория вообще не знает ничего об индексах
Верно, на самом деле я немного утрирую, только для CLUSTERED PK он обязан создаваться (по смыслу CLUSTERED), для NONCLUSTERED тоже не обязательно.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
23.07.2004, 14:32
    #32618899
ChA
ChA
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Ссылочная целостность
Сергей Васкецов только для CLUSTERED PK он обязан создаваться
В теории РБД мне также не встречалось понятие CLUSTERED, это опять же
относится к реализации.

P.S. Истины для...
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
  1  все
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / Ссылочная целостность / 25 сообщений из 42, страница 1 из 2
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]