ser_shuМозгопудренство - это практика подмены устоявшихся понятий (в рассмотренном случае - считать неудаленное удаленным, почти всегда и почти всем согласно особым условиям реализации).
На меня намекаете? Ай-ай-ай.
На самом деле наоборот, многие путают удаление логическое и удаление физическое. И логическое удаление не должно сопровождаться физическим (за исключением случаев, если вообще весь блок данных не представляет интереса).
Представьте, при смерти человека удаляются все упоминания о нем, архивы, документы, в день смерти стирается память родных, исчезают все личные вещи, исчезает даже могила, в которой его только что похоронили. Чудесно? Почему в норме вещей такое происходит в БД?

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

Нету тут ни смысла, ни чести, и совершенно не пахнет совестью.
Будущее за ИС, которые будут делать большую часть работы за человека (так как системы становятся все сложнее и сложнее).

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

Для примера, если я говорю не очевидные вещи: вспомним реляционную модель.
Она ведь не такая уж простая для обывателя, и нужны какие-то усилия, чтобы понимать ее.
Но она позволяет часть программирования перевести в оперирование метаданными, что дает значительный прирост скорости разработки, легкость модифицирования, оптимизации, контроля и т.п. Но я верю, что это только начало. В некоторых областях программирования хорошо показывает себя объектная модель. Но и это не абсолют, это всего лишь одна из моделей.

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

По опыту знаю, что программисты обычно считают ниже своего достоинства разбираться в таких вещах, но по сути это механизм оперирования массивами данных, при этом совершенно отличный от языка sql, а по функциональности..., ну, по крайней мере, многие вещи в экселе делаются проще.
И, как говорили в этом топике "рынок покажет". Что показывает рынок по экселю ;-)
Может быть, будущее ИС не в развитии реляционных баз, а в развитии Экселя?

PS. Сказка ложь, да в ней намек

Че-то вспомнился по этому поводу MX-ALEX

БредятинаСлушаюсь и повинуюсь:) Извините за беспокойство:)
ААА! Ну вот опять раздел в анабиоз впадет. То хоть можно было почитать, отвлечься от работы

Вы опошляете реальность до конкретных действий: использовал инструмент - получил результат, использовал другой инструмент - получил худший результат за большее время и с большими затратами.

Но вы упускаете то, что за этим стоит нечто нематериальное, но очень важное, гораздо более важное, чем конкретные кнопки - ИДЕЯ. И именно идея позволяет не разваливаться на кусочки всем этим маленьким, материальным, видимым снаружи, но гораздо менее значимым вещам.
И идей, на самом деле, очень мало. В основном мы видим одни и те же идеи, по разному (и с разным качеством) реализованные в разных системах, с маленькими, не особо значащими деталями.
Одна из таких идей - реляционная модель, которая доминирует на рынке СУБД. Бредятина, кстати, рекламирует, по сути, ту же реляционную модель сущность-связь, но в каком-то своем диалекте. Другая модель - объектно/процедурная, она доминирует в разработке приложений.
Третья идея - модель глобалов языка М.
Четвертая идея - кубы OLAP
Пятая идея - система формул электронной таблицы
Шестая идея - система правил языка пролог
ну и так далее.

Несмотря на то, что у каждой конкретной реализации есть титульная идея, как правило, одна идея является ограниченной и недостаточной для построения полнофукционального приложения, и поэтому в какой-то мере она поддерживает другие технологии.
Примеры:
Excel - формулы электронной таблицы, процедурное/объектное программирование, кубы OLAP.
Каше - модель глобалов, реляционная модель, объекты, кажется в DeepSee есть OLAP.

То есть мы видим, что в рамках одной идеи не получается создать универсальную систему.
Но вопрос идеологии, нахождения достаточно жесткой модели для конструирования ИС, чтобы она была хорошо формализуемой, а с другой стороны достаточно гибкой и универсальной - да, это серьезная задача, в своем роде это поиски Грааля для средневековых рыцарей или философского камня для алхимиков. К слову сказать, философский камень хоть и не нашли, но из их поиски были не зря;-)

Однако у меня в иногда создатеся впечатление, что рекламируете. Ну да суть не в этом :-)

Согласен, реляционная модель и модель сущность-связь не одно и то.
Но чисто внешне, на уровне модели, они имеют много общего, причем ваша модель еще жестче и требовательней к формализации, чем реляцоннная. Наверняка это должно давать свои преимущества в работе с системой, новые методы, новые возможности. Какие?


Симбиоз идей это тоже интересный вопрос, так как если бы это не было проблемой, то в любую систему можно было бы напихать все подряд. И я согласен, что М является хорошей почвой для других идей.

В том же Аксессе можно без программирования создать функциональную СУБД. Так почему же он не захватил весь мир?

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

Попробую проиллюстрировать это примером.
Пусть у нас есть алфавит, скажем 33 буквы. Использовать 33 буквы неудобно - в каждом слове легко можно сделать ошибку, ну и вообще куча ненужной работы для составления слов.
Давайте будем составлять слова из промежуточных агрегатов - слогов. Пусть для простоты у нас слоги двухбуквенные, их уже гораздо больше, теоретически до тысячи. Можно для простоты исключить неиспользуемые слоги (ыы, жи-ши и т.д.) и тем самым немного сократить количество ошибок. Работы при составлении слов намного меньше, но иногда в экзотических случаях оказывается, что нужных слогов нет, а они нужны. Тогда системе нужен инструментарий для составления новых слогов из букв. Также при таком подходе остается большим количество ошибок.
Можно использовать слова, но тогда база ИС распухает до неимоверных пределов, и рано или поздно окажется, что каких-то слов она не знает.
А алфавита, в котором есть одновременно и буквы и слова не придумали. Тогда делают гибридную ИС, в которой есть разные слои представления, средства создания одного слоя из другого и т.п.

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

К чему это все я? Настоящая мощная ИС должна давать доступ "к буквам". Все вот эти "сделать одной кнопкой" на самом деле очень ограничены.
И я говорю не только про М/Каше, та же объектно/процедурная модель построена так же.
Если говорить про мастер/детайл, накладные и т.д., то мы уже явно загоняем себя в угол. Можно создать очень удобную систему, но она будет удобна только в очень узкой области.