Естественное для заказа понятие - состояние. "Выполнен", "выполняется", "оплачен", "готов к выполнению" и так далее. Все описанное - вполне в это ложится.

Дальше - можно смотреть. Например, завести для выполненных и прочих "архивных" заказов отдельную партицию.

а обязательно ли вообще отделять текущие заказы от выполненных в 2 разные таблицы, можно же просто всё в одной таблице с полем выполнен/выполняется... ???
Я специально употребил термин "партиция" - очень удобный механизм. Если партиций нет - надо думать, какое решение будет более удобным. Я бы сказал, стоит держать в одной таблице, пока объем исторических данных не станет мешать в оперативной деятельности.

sql200051. а что такое партиция что это за механизм ?
Отвечу чуть ближе к железу: это механизм, который позволяет одной логической таблице (собственно таблице) состоять из нескольких физических (партиций). Скажем, у Вас в базе лежат партиции ЗАКАЗЫ_1999, ЗАКАЗЫ_2000, ЗАКАЗЫ_2001.... В тот момент, когда выполняется запрос вида select * from ЗАКАЗЫ where год between 1999 and 2000 - он выполняется над партициями ЗАКАЗЫ_1999 и ЗАКАЗЫ_2000. Ну и идет накрутка возможностей - например, такой запрос может быть распараллелен.

Преимуществ - немеряно. Во-первых, можно использовать все плюсы как единой таблицы, так и разбиения таблиц. А во-вторых, можно плавно перейти к партициям, не внося изменений в существующий код (DML), но используя их преимущества.

sql20005
(за 2 года...например) нам клиент говорит... хочу выполнить заказы тамже где и в прошлый раз...

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

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

sql20005потом когда через года 3 там будет дофига записей, можно будет безболезненно добавить партиционирование, или это нужно обязательно сразу продумать ?
Для добавления партиций в непартиционированную таблицу достаточно на несколько минут исключить доступ к этой таблице (независимо от размера). Добавление новых партиций - полностью on-line операция.

sql20005Этож получается панацея от всех бед какая то...
Да собственно так и есть. И еще разные интересные аспекты, о которых Вы не упомянули.

sql20005Теперь отложу разработку OLAP, и со спокойной совестью буду делать своё OLTP
Вы только сначала убедитесь, что у Вас партиции есть :)

sql20005вы имеете ввиду что не во всех СУБД есть партиции ??? - у меня Oracle...
Еще и не во всех редакциях Oracle...

sql20005Блин!!! ещё одна проблема вырисовывается!!!
а как делать собственно удаление строк ???
В абсолютном большинстве случаев (известных мне) из базы почти ничего не удаляется. Как только с записью происходило что-то интересное - ее и по бизнесу, и по реализации удобнее зафиксировать навсегда (возможно - в архив). Удаляются только записи статуса "простая бумажка" - например, ошибочно введенные, или те, где клиент сразу же отменил заказ.

sql20005Что в Standart eddition One, и в Standart Eddition для 9-ки - нету ?, только в Enterprice ?
Не уверен насчет SE One, но кажется так.

sql200051. да... а как определить например оператор ввёл по ошибке клиента, и удалил потом его физически, или просто удалил старого клиента ?
Это должен определить сам оператор - и по результатам нажать "Удалить" либо "Перенести в архив". А программа должна не позволить удалить клиента, с которым уже происходило что-то интересное - в простом варианте просто благодаря наличию ссылок на этого клиента (foreign keys, например, из заказов).

sql20005Т.е. прога же незнает что есть ошибочно введённые данные, а что не ошибочно... и какие заказы сразу отменились а какие не сразу... как с этим быть ?
"Какие отменились сразу, а какие не сразу" - прога знает. Логика в каждом случае может быть разной, нужно смотреть по месту. Для документов обычный вариант - стартовое состояние "просто бумажка"; только в этом состоянии документ может быть физически удален, и как правило - если документ переведен в другое состояние, вернуться в это он уже не может.

sql200052. как быть с удалением/восстановлением и с master/detail, т.е. например если мы логически удаляем master... ???
Зависит от бизнеса. Вариантов в принципе два: либо "логически удалить детали", либо "оставить детали как есть" - все равно до них не доберешься.

В целом, я бы избегал мысли о "логическом удалении". "Состояние" - это более универсальная и более удобная метафора.

sql20005
Както всё это сложно(п2,п3), может есть какойто более правильный и простой путь, подскажите... ?
Ну например, часто достаточно обойтись пунктом 4, а второй и третий абсолютно не нужны.

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

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

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