|
|
|
не удалять данные по внешним ключам
|
|||
|---|---|---|---|
|
#18+
Tanya_0306Начало как в моей истории .... Только вот проект заваливать не хочется ..... Надо разумные доводы привести почему так делать нельзя .... Он говорил про 1с - там кодом (идентификатором может быть и строка и число) и еще Навижен (не работала в нем). Говорит там тоже уникальный код - это может быть краткое наименование (текстовое поле).Скажем так... Основное требование, которому должен удовлетворять первичный ключ - уникальность. Про обязательное использование какого-либо конкретного типа данных Вы нигде ничего не найдете, не говоря уже о том, что ключи могут быть составными (из нескольких полей с разными типами данных). А по поводу "автоматических" каскадных операций... Если с каскадными обновлениями еще можно как-то смириться, то каскадные удаления - зло, из-за которого вполне реально огрести немалых люлей: удалив одну запись в одной таблице (в зависимости от расположения звезд на небе) можно получить "девственно пустую" базу данных. И, в зависимости от типа сервера, необходимо учитывать технические ограничения при выполнении каскадных операций. ЗЫ. Возможно, Вам нужно обратиться в несколько в более специализированный форум - Проектирование БД ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.10.2013, 11:26 |
|
||
|
не удалять данные по внешним ключам
|
|||
|---|---|---|---|
|
#18+
Tanya_0306в базе данных есть таблицы Контрагент , Организация и Договор. в таблице договор создала внешний ключ к таблицам контрагент и организация. подскажите как реализовать следующее при попытке изменении записи в таблице контрагент и организация- выдавать предупреждение если данные используются в таблицы Договор. подскажите как это кодом проверяется .... Я так понимаю, предполагается менять неключевые атрибуты в таблице контрагент и организация ? Написать запрос, который проверяет наличие записей в связанных таблицах. Выполнять его перед каждым изменением записей в родительских. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.10.2013, 11:43 |
|
||
|
не удалять данные по внешним ключам
|
|||
|---|---|---|---|
|
#18+
Relic Huntersphinx_mvВнешний ключКак это поможет "попытке изменении записи" ? >>> Tanya_0306 проверить наличие Код: sql 1. этот запрос неправильный. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.10.2013, 11:44 |
|
||
|
не удалять данные по внешним ключам
|
|||
|---|---|---|---|
|
#18+
sphinx_mvTanya_0306в базе данных есть таблицы Контрагент , Организация и Договор. в таблице договор создала внешний ключ к таблицам контрагент и организация. подскажите как реализовать следующее при попытке изменении записи в таблице контрагент и организация- выдавать предупреждение если данные используются в таблицы Договор. подскажите как это кодом проверяется .... Внешний ключ - одно из средств поддержания ссылочной целостности в базах данных. Его использование уже само по себе является необходимым и достаточным решением для Вашей задачи - в подавляющем большинстве случаев. Внешние ключи тут ни при чём. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.10.2013, 11:45 |
|
||
|
не удалять данные по внешним ключам
|
|||
|---|---|---|---|
|
#18+
Tanya_0306Где-то в степи, Можно без "Тетеньки". В качестве уникального идентификатора записи используется текстовое поле. Это не моя идея, выше стоящее руководство так требует. Я бы создала идентификатор - код, инкрементное поле. Но начальник сказал - НЕТ. ЗАЧЕМ?? Начальник -- идиот. Это нормально. А вот то, что ТЫ -- разработчик -- не хочешь брать на себя решение технических вопросов -- очень странно. Tanya_0306Ну и соответственно пользователь может решить изменить "кг" на "Кг." Примерно такая ситуация .... Если пользователь МОЖЕТ ИЗМЕНИТЬ поле, то УЖЕ заведомо это поле НЕ ДОЛЖНО служить первичным ключём или его частью. Потому что первичный ключ неизменяем, это аксиома. Потому и ржак в теме такой, после твоего этого сообщения. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.10.2013, 12:03 |
|
||
|
не удалять данные по внешним ключам
|
|||
|---|---|---|---|
|
#18+
sphinx_mvСкажем так... Основное требование, которому должен удовлетворять первичный ключ - уникальность. ] И неизменяемость. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.10.2013, 12:07 |
|
||
|
не удалять данные по внешним ключам
|
|||
|---|---|---|---|
|
#18+
Обычно никто не заморачивается поиском первичного ключа среди атрибутов. Вместо этого сразу ставят автоинкрементное поле. Так мороки меньше будет. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.10.2013, 13:05 |
|
||
|
не удалять данные по внешним ключам
|
|||
|---|---|---|---|
|
#18+
Pallaris, Он "утверждает" структуру базы данных ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.10.2013, 13:22 |
|
||
|
не удалять данные по внешним ключам
|
|||
|---|---|---|---|
|
#18+
Alex Kuznetsov, А Вы не подскажите эти самые доводы. У меня только один - "так принято у каждой записи должен быть уникальный идентификатор скрытый от пользователя". Но это не аргумент ) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.10.2013, 13:24 |
|
||
|
не удалять данные по внешним ключам
|
|||
|---|---|---|---|
|
#18+
Tanya_0306А Вы не подскажите эти самые доводы. "Попомните мое слово!" и "Когда вы будете горько плакать и вспоминать об автоинкрементном первичном ключе" ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.10.2013, 13:29 |
|
||
|
не удалять данные по внешним ключам
|
|||
|---|---|---|---|
|
#18+
Tanya_0306Pallaris, Он "утверждает" структуру базы данных Пусть утверждает. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.10.2013, 13:37 |
|
||
|
не удалять данные по внешним ключам
|
|||
|---|---|---|---|
|
#18+
Tanya_0306, Какие атрибуты родительской таблицы предполагается менять ? Я так понимаю, предполагается менять неключевые атрибуты в таблице контрагент и организация ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.10.2013, 13:38 |
|
||
|
не удалять данные по внешним ключам
|
|||
|---|---|---|---|
|
#18+
<Задумчиво> неужели она считает, что на работу ее взяли что бы программировать программы ? </Задумчиво> ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.10.2013, 13:42 |
|
||
|
не удалять данные по внешним ключам
|
|||
|---|---|---|---|
|
#18+
MasterZivsphinx_mvСкажем так... Основное требование, которому должен удовлетворять первичный ключ - уникальность. ]И неизменяемость.Теория этого не требует. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.10.2013, 13:55 |
|
||
|
не удалять данные по внешним ключам
|
|||
|---|---|---|---|
|
#18+
Relic Huntersphinx_mvВнешний ключКак это поможет "попытке изменении записи" ? Ну, попробуйте сменить значение первичного ключа, поля которого участвуют в проверяемом внешнем ключе с кляузой "ON UPDATE NONE". При этом особых проблем со ссылочной целостностью даже наличие кляузы "ON UPDATE CASCADE" ни разу не наблюдается. Только "ON UPDATE NULL" может пропустить изменение, и может быть получена куча записей с "потеряными" связями. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.10.2013, 14:08 |
|
||
|
не удалять данные по внешним ключам
|
|||
|---|---|---|---|
|
#18+
Tanya_0306... "так принято у каждой записи должен быть уникальный идентификатор скрытый от пользователя". Но это не аргумент )Конечно не аргумент, потому что существует такое понятие как ненормализованные данные, которые не требуют наличия уникального ключа для каждой записи. По поводу аргументов, бейте своего начальника его-же доводами (ну это только в случае если он не самодур и может адекватно воспринимать критику). В 1С уникальный идентификатор записей уникален не то что в пределах одной таблицы, а в пределах всей базы данных, т.е.: Клиент IDКод НаименованиеAF01217 ВЛ-093425 Клиент 1AF01234 ВЛ-093426 Клиент 2 Контракт IDКод НаименованиеAF01218 ЦО-002453 Контракт ЦО 2453AF01222 Ф1-000026 Контракт Филиал 26 ДокументБухгалтерии IDКод НаименованиеAF01219 ЦО-785903 Документ ЦО 6344AF01220 Ф1-456372 Документ Ф1 567 Таким образом пользователь увидит клиентов с кодами ВЛ-093425 и ВЛ-093426, контракты с кодами ЦО-002453 и Ф1-000026 и документы с кодами ЦО-785903 и Ф1-456372. А связаны они будут между собой с помощью идентификаторов, к которым шаловливые ручки пользователей доступа не имеют, соответственно обновления не будут затрагивать подчинённые таблицы. Удаление - да, а обновление нет, т.к. ID не изменяется. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.10.2013, 14:27 |
|
||
|
|
start [/forum/topic.php?fid=20&msg=38415441&tid=1403932]: |
0ms |
get settings: |
9ms |
get forum list: |
13ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
103ms |
get topic data: |
10ms |
get forum data: |
3ms |
get page messages: |
51ms |
get tp. blocked users: |
2ms |
| others: | 12ms |
| total: | 211ms |
| 0 / 0 |
