Интересно было бы сравнить системы учета (типа 1с, Navision Attain, Axapta, Oracle 11i, ...) c точки зрения структуры базы данных, а не прикладных наворотов, которые хараткеризуют скорее вылизанность. Может к-н поделится размерами баз, количеством проводок, записей в номенклатурных справочниках...
Это могло бы помочь определиться желающим создать свою учетную систему - стоит ли писать что-то свое или все велосипеды давно изобретены:)

хотелось бы услышать и про SAP и BAAN. Можно про Парус и Галактику

авторВы путаетесь с базами и надстройками над ними

что касается Oracle 11i, то Oracle E-Business Suite 11i содержит (http://www.oracle.com/ru/applications/Funct_bl/index.html?Funct_StObz.html)
ERP решения и является ПРИКЛАДНОЙ системой

авторТо, что Вы называете наворотами, на самом деле является обычным, можно

даже сказать рутинным программированием. А запрограмить можно все.

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

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

насколько мне известно, триггеры, хр и constrains присутствуют только в системах, внутреннюю структуру которых нельзя изменить при настройке

авторпро SAP R/3 вряд ли кто расскажет - как-никак порядка 11000 таблиц
есть подозрение, что реально НОВЫХ объектов там немного, в основном разновидности справочников, документы и журналы док-в, всевозможные хранилища промежуточных результатов..

дурацкий вопрос - почему системы, которые создают свои объекты на основе нескольких физических таблиц, используют РЕЛЯЦИОННЫЕ, а не ОБЪЕКТНЫЕ СУБД?

автор SergueiF
насколько мне известно, триггеры, хр и constrains присутствуют только в системах, внутреннюю структуру которых нельзя изменить при настройке

авторmir
Бред какой-то.

Вы знете хоть одну УЧЕТНУЮ СИСТЕМУ, которая бы позволяла пользователю изменять свою внутреннюю структуру и использовала бы триггеры или хр ?

- тема:ПРИКЛАДНЫЕ базы(под этим я имел ввиду надстройки над обычными базами - Oracle, MSSQL..., создающие СВОИ объекты из обычных таблиц и ипользующих эти объекты для ведения учета - типа 1с, Navision Attain, Axapta, Oracle 11i, SAP, BAAN, Парус, Галактика, Scala....)

авторХотелось бы кое что уточнить. Не в порядке "наезда", полагаю, что сказанное ниже вы знаете не хуже меня. Надеюсь, что терминологическая неточность есть следствие торопливости.
Так вот. Нет никаких "обычных баз - Oracle, MSSQL...". Это называется СУБД. Нет никаких "прикладных баз". Это называется информационные системы. Любая информационная система, использующая реляционную СУБД, создает свои объекты из обычных таблиц и ипользует эти объекты для решения своих задач
согласен, прошу прощения за простоту :)
Я имел ввиду даже скорее не просто информационные системы(получается слишком обще), а учетные системы - приводя конкретные примеры я хотел избежать моногословия(и рекламы эих самых систем:)
авторЧто вы понимаете под "внутренней структурой" и, соответственно, меняющей ее "настройкой" системы?
"заказные" программы, написанные под конкретную задачу, как правило имеют неизменную внутреннюю структуру объектов, которая для модификации требует специалиста как по СУБД, так и по реализации бизнес-логики. При создание учетных систем приходится сталкиваться с похожими задачами организации хранения и доступа к данным, отличающимися лишь реализацией предметной области. Лучше по этому поводу почитать у Navision, 1c и иже с ними, которые предоставляют КОНСТРУКТОР для решения бизнес-задач на основе объекты из обычных таблиц СУБД. Тем самым можно ограничиться только специалистом по бизнес-логики(если знать, что бизнес объекты правитьно и ОПТИМАЛЬНО отбражаются в СУБД)

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

кое-что удалось накопать по Аксапте и Аттейну

Разделение таблиц между компаниями - в Аксапте - возможны комбинации, в Навижн - только 2 опции - "общая для всех" и "у каждого своя"
Разделение доступа по записям в Навижне декларируется (для опции SQL), но не очень-то работает, в Аксапте - работает.
Доступ к таблице на поле - в Аксапте есть, в Аттейне нету.
В Акзапте - есть табличные коллекции, в Аттейне - нету
В Акзапте - есть разграничение доступа по доменам, в Аттейне - нету.
В Акзапте механизм конфигурационных (или функциональных) ключей серьезно упрощает любую настройку доступа.
В Акзапте - трехзвенка, двухзвенка, WEB-клиент или терминал, в Аттейне - только двухзвенка, WEB-клиент или терминал. В Аттейне через эту трехзвенку работает портал. Обычный клиент через нее не работает. Считать это трехзвенкой или нет - вот в чем вопрос.
Возможности Аттейна при количестве более 100 сомнительны, а при количестве пользователей более 500 - официально считаются невозможными. Про Акзапту - данные известны.
Ограничения собственной БД Аттейна - 64 Гб, на SQL - производительность ниже, чем на своей БД. Акзапта "своей" БД не имеет, так что сравнивать не с чем (разве что с Ораклом или SQL).
Акзапта - пашет на Оракле, Аттейн - нет.