Основним елементом оригінальної технології (тобто, розробленої авторами, а не кальки існуючої) є найперше досить вдалий, як на нашу думку, спосіб опису даних, використання якого і дозволило доволі простими засобами забезпечити і використання міжпроцесних комунікацій, і генерацію звітів, і побудову SQL запитів, і елементи автоматичної синхронізації відображень з структурами даних тощо. На жаль, серед існуючих генераторів SQL нами не було знайдено таких, які дозволяли розв'язувати ці (і інші) задачі комплексно
http://www.codegeneration.net/generators.phpЯ підозрюю, що там можна знайти щось подібне. Хоча, звичайно, краще мати утиліту заточену під свій проект, тому що розробка і використання універсального генератора надто дорога - індус дешевший.
кілька власних розробок генераторів шановного модератора це також мають підтверджувати..., до речі, навіщо так багато???
Різні замовники, вимоги, технології, мови програмування, etc... Напр. дизайн дуже залежить від того, що вибрано основною схемою - структура бази даних, структура класів чи якийсь схеми опис в XML/TXT. Ну і універсальна мова для цього вже є - SQL. :-) Чомусь написання універсального редактора БД займає значно менше часу ніж спеціалізованих надбудов.
Я так зрозумів, що ви описуєте схему в окремому файлі й на основі нього генеруєте код і базу. Це (з мого погляду), один з найкращих підходів, хоча й не позбавлений недоліків, характерних для метапрограмування, такі як необхідність вивчення нової мови і, відповідно, написання талмуду з описом цієї мови для замовника/розробників.
На наш погляд, цікавий підхід запропоновано в проекті Django, хоча для цього підходу очевидні і проблеми побудови складних запитів.
Ліньки розбиратися в ньому.
Ще однією важливою складовою технології є поєднання описів даних з застосуванням в проектах елементів автоматного програмування.
Слабко уявляю що це таке (поєднувати можна по всякому), але так як це суперсекретний проект, то розпитувати не буду.
Сукупним наслідком використання цих рішень є те, що більшість програм, представлених на http://www.cetus.com.ua мають розмір близько 400-800 рядків програмного коду на С++ (без урахування ядра) (і це при повній функціональності кожної програми по збереженню даних, генерації звітів, налаштування відображень). На поточний момент автори зайняті вдосконаленням використаного підходу, що дозволить зменшити обсяг коду ще на 30-40 відсотків.
0.5-1 тисяча рядочків коду без врахування ядра - це (на мій погляд) не таке вже й маленьке число (1-4 тисячі з коментарями, докою і тестами). В таких об'ємах можна досить серйозні аплікації писати й без використання суперядра.
Як підсумок, можливо було б доцільним розглянути і порівняти засоби структурування даних в різних проектах, що використовують бази даних (і в т.ч. комерційних) і їх вплив на якість отриманого програмного коду.
Цікаво було б. Тільки "засоби структурування даних" - трішки розпливчасте поняття. Мається на увазі, які є підходи для обміну об'єктними даними між програмою та реляційною БД? Чи які є підходи щодо побудови архітектур CRUD(Create-Retrieve-Update-Delete)-аплікацій?
