sql20005здесь проблема следующая... не все операторы наверное должны иметь доступ к возможности физического удаления!!!
Почему? Я не вижу причин запрещать удалять свои записи в состоянии "просто бумажка". Впрочем, это в любом случае вопрос бизнес-правил.

sql20005потом удаляет... а прога незнает нужно удалить или нужно пометить... поетому она всегда помечает!!!
Программа в данном случае не должна решать.

sql20005еслиже юзер имеет и кнопочку удалить и кнопочку пометить, то это уже не то...
Именно. Он должен иметь кнопку удалить и кнопку "перенести в архив". Обе работают только для определенных состояний документов (например, заказ в состоянии "выполняется" блокирует обе возможности).

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

Безусловно, Вы можете делать и стопроцентную неудаляемость - ничему принципиально не мешает.

sql20005несовсем понятен термин просто бумажка...
если док является бумажкой до того как к нему прикреплены дочерние сущности
Термин неформальный :) Я бы сказал, документ является просто бумажкой до тех пор, пока не отразил важного для программы события, случившегося в реальном мире. "Клиент пришел и начал диктовать заказ" к таким событиям не относится. "Клиент выразил готовность оплатить заказ" - относится. Примерно так. Наличие ссылок - является довольно точной эвристикой для этого понятия, но не более.

С моей точки зрения, удобен следующий подход: у документа существует явно выделенное состояние "просто бумажка". В этом состоянии на него нельзя ссылаться (то есть он не фигурирует в списках выбора для других операций). Его можно только редактировать, удалить либо "подтвердить" (перевести в следующее состояние). После перевода обратный переход к "просто бумажка" невозможен (или возможен, но сочетается с детальной проверкой допустимости).

sql20005
Удалять скорее всего нельзя, примеров море при удалении корпорации нельзя удалять все её торговые точки...
Если у корпорации уже есть торговые точки, у них есть оборот итп - безусловно, ее можно "закрыть", но нельзя "удалить". Удалить можно, если оператор по ошибке нажал "создать корпорацию" дважды.

sql20005
Ничего не делать - если это просто тихо удалить то это неверно, т.к. юзеры потом долго плеваться будут почему у меня владелес точи компания сусел мыже удалили её 3 года назад...
Это зависит исключительно от бизнес-логики и ни от чего другого. Определяется и реализуется в каждом конкретном случае. Универсального решения нет и не может быть.

sql20005
если это всмысле запрет удаления, или какаято замена, тогда правильно но опятьже проверять все дочерние таблицы это ужасно!!! - для каждой таблицы проверять все дочерние...
Хм. Если коротко, сложная бизнес-логика и реализуется непросто. При этом, безусловно, существуют все обычные возможности "автоматизировать часто повторяющиеся операции" - как и везде в программировании. Но магического решения "в два счета сделать сложную вещь" я бы не ожидал.

sql20005
а нужно то:
1. корзина(т.е. страховка от случайного удаления)
Не годится. "Случайного удаления" в смысле "чтобы потом можно было восстановить важные для программы данные" вообще не должно происходить. Если же оператор грохнул "просто бумажку", а потом решил ее повторить - можно, конечно, сделать ту или иную корзину, но имхо полезность этого не стоит усилий.

sql20005
2. скрытие данных которые ненужны, но которые нельзя удалять, так как они используються гдето в отчётах...
Так и делается.

sql20005
можно както это просто сделать ?, ато я вижу только сложное решение -
см мой предыдущий пост ???
Обычно это просто и делается. Если Вас привлекают каскадные операции - используйте ON UPDATE CASCADE там, где он есть, либо напишите простенькую подпрограмму, которая будет "пробегать по всем дочерним" - максимум полсотни строк.

sql20005т.е. безусловное логическое удаление удалили клиента и всё... а как быть с целостностью данных ? ведь у клиента могут быть текущие заказы...
И что? Тут есть два варианта. Бизнес-аналитик может сказать "нельзя архивировать клиентов, у которых есть текущие заказы" - надо будет проверять. Также он может сказать "архивируйте на здоровье. Старые заказы довыполняются обычным образом, но новых не сделаешь, пока не вытащишь из архива". Так и делаете.

sql20005чувствуете чегото нехватает.... мне кажется именно пп2,3... :-)
Помимо прочего, не стоит навешивать на триггера слишком много. Сложные бизнес-операции лучше делать процедурами. В ряде случаев - из триггера стоит вызывать процедуры. Надо смотреть оптимальное решение в каждом конкретном случае.

sql20005В процедуре, делаю вложенную транзакцию, в ней физически удаляю запись!!! далее в любом случаи делаю откат транзакции всё!!!
В принципе можно - но не думаю, что это будет хорошим решением. Как минимум, это заметная лишняя работа для сервера.

sql20005 Юзер хочет избавиться от записи. Он типа жмёт удалить - база ругается типа удалить нельзя.
тогда он нажимает скрыть.
(или подругому: одна кнопочка удалить и в зависимости от статуса записи происходит
удаление или скрытие)
В первую очередь, юзер должен четко понимать разницу между "удалить" и "скрыть". Вариант "одно не прошло, нажимаем второе" означает либо неудачную реализацию бизнес-логики, либо пользователя, который не понимает логику системы.

"Одна кнопочка" - категорически недопустимо, поскольку это _разные_ действия. Вы подсознательно считаете их двумя вариантами одного действия - отсюда и все остальное.

sql20005
Далее действия над child записями полностью ложатся на бизнес логику, и определяются в
общем для каждой таблицы отдельно!!!.
Никто не мешает писать универсальные процедуры для автоматизации часто встречающихся фрагментов бизнес-логики. Но в принципе бизнес-логика - это набор именно что отдельных, частных решений. Мало того, в ходе сопровождения системы именно бизнес-логика меняется наиболее непредсказуемым образом - поэтому универсальные решения здесь можно внедрять только на глобальном уровне (некий собственный универсальный движок, достаточно кастомизируемый и гибкий для прикладных требований).

sql20005
1. нужно ли в записи иметь атрибут - отдельное поле бумажка эта запись или нет ?
В большинстве случаев - у документа есть объективно необходимое поле "состояние", и "просто бумажка" - одно из состояний. Если нет ничего подходящего - нужно добавить поле.

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

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

sql20005
3. подтвердить это как я понял специальная кнопочка, при нажатии на которую,
запись фактически потом уже удалить нельзя будет - да ?
Подтвердить - это нечто, что выполняется при любой операции использования записи либо перед ней. Есть два варианта. Допустим, есть счет в состоянии "просто бумажка".

1. Жмется кнопка "готов к оплате" - что собственно и есть "подтвердить". После этого счет может быть выбран бухгалтером или кассиром, но уже не может быть удален продавцом.

2. Бухгалтер или продавец сразу жмет "оплатить" - при этом счет опять-таки неявно "подтверждается".

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

sql20005
А что например можно сделать с чаилдами Местами продаж,
если нужно для них установить владельца = null,
при логическом удалении ихнего владельца ?
Видите ли, такие вещи не являются универсальными. Скажем, завтра клиент может сказать - не хочу чтобы становились null, хочу, чтобы привязывались к головному офису.

sql20005
как например может в этом помочь ON UPDATE CASCADE
Он как раз сказанное и делает. Но поскольку его в оракле нет - вопрос теоретический.

Впрочем, возможно Вам понравится работать в ErWin - его можно сконфигурить так, чтобы он автоматически генерил подобные каскадные триггера. Скорее всего, другие CASE - аналогично.

sql20005например у заказа есть отрезок времени date_begin, date_end.
логично сделать так, что пока не наступила date_begin, заказ - в состоянии просто бумажка; когда наступает время date_begin - заказ переводиться в состояние выполняется, а когда date_end - выполнен.
Хм. Не могу сказать, что такая схема нигде и никогда не будет уместна - но как-то положительных примеров в голову не приходит.

База отражает события реального мира. В такой модели, с моей точки зрения, как только наступает date_begin, утром, заказ должен выскочить на экран с напоминанием о том, что его пора выполнять - и кнопочками "начать выполнение", "отложить", возможно еще какими-нибудь (точнее, уместнее если выскочит список "подошедших" заказов). Завершение - тем более; могут идти любые предупреждения, список просроченных заказов итп - но я не представляю себе автоматического завершения. Это ответственная, денежная операция; у компьютера нет оснований нажимать кнопку "за пользователя".

sql200052. основной вопрос: по системному времени это делать очень удобно, но если какойто урод поменяет время, или неправильно часовой выставили и время нетак переставляться будет, или ещё что то(замена компа например...) то с заказами будет полная лажа...
Серверное время - важная штука. Если с ним бедлам, проблем будет много и в самых разных местах.

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

sql20005... а вообще например если закончился например срок договора, то он может быть переведён автоматически в состояние просроченный ?
Давайте так - чтобы действительно не утонуть в выяснениях. Для того, чтобы по времени можно было делать операции, нужно:

а) Чтобы эта операция зависела только от времени, но не от событий реального мира. Чтобы это была "чисто логическая" операция.

б) Чтобы на выбор: серверному времени можно было достаточно доверять, либо операция не влекла за собой неприятных последствий (например, клиента не обслуживают по договору, так как из-за сбоя времени у него проставился флажок "закончился").