спросите у Яндекса или поищите в этом форуме. Количество реинкарнаций зашкаливает.

LSV
Выбиться "в люди" сможет только реально простая и удобная система. Интуитивно понятная, с простой и эффективной SQL-структурой.

уже одно наличие какой-то SQL-структуры является ограничением. Любые структуры должны создаваться разработчиком

LSViscrafmLSVВыбиться "в люди" сможет только реально простая и удобная система. Интуитивно понятная, с простой и эффективной SQL-структурой.
уже одно наличие какой-то SQL-структуры является ограничением. Любые структуры должны создаваться разработчикомА где речь про запрет создания ч-л разработчиком ?
Никаких ограничений. Просто нужно соблюдать ряд несложных правил. И не лепить велосипедов.
ограничение даже в том, что разработчик работает в рамках заложенной кем-то какой-то SQL структуры.

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

g_box, судя по всему речь идет о каком-то ORM. Ищите себе инструмент по этому ключевому слову.

LSV
iscrafm, не пойму к чему Вы клоните...
к тому, что добавление в платформу бизнес-объектов, типа Справочник, Документ, Регистр и т.п. - первый шаг к превращению платформы в "дорабатываемое приложение", со всеми вытекающими последствиями, естественно.

LSVпервый шаг к превращению платформы в "дорабатываемое приложение", со всеми вытекающими последствиями, естественно.Вы о том, что за этим последует неизбежная модификация самой платформы ?
Вовсе не обязательно.
Хотя в ряде случаев и такое необходимо.

Так живут и развиваются все платформы. Разве нет ?
так живут и развиваются дорабатываемые приложения. Платформа должна быть независима от приложений, разработанных для нее, точно так же как и приложения от платформы. Представьте что Excel, как платформа, обязывает хранить сумму только в колонке G. Естественно, Вы как разработчик можете добавить и M и даже ММ, но итоги и формулы будут работать только с колонкой G. Единственное правило, которое в данном примере важно с точки зрения платформы, должно звучать так: все данные должны быть размещены в ячейках. Но никак не: суммы должны храниться в ячейке G, справочники в таблице SUPERDICTIONARIES и т.п. В первом случае это будет действительно платформа, во втором - приложение, которое можно доработать, нарастить функционал и т.д. Как только данные не влазят в отведенные рамки (см. рис. с кирпичами), встает проблема выбора: доработать функционал базового приложения (а не платформы) или пожертвовать потребностями.