3. Зачем? - это ведь отнюдь не очевидно.
4. Может и от компиляторов откажемся по тем же причинам?
5. Ничего нельзя проектировать "снизу", даже маленькие системы. Вообще, привидите хоть один пример проектирования "снизу", даже в программировании не могу себе представить как из классов делают классы родители, абстрактыне классы ... это как писать ТЗ на готовую систему.

mazzy gybson
4. Может и от компиляторов откажемся по тем же причинам?
5. Ничего нельзя проектировать "снизу", даже маленькие системы. Вообще, привидите хоть один пример проектирования "снизу", даже в программировании не могу себе представить как из классов делают классы родители, абстрактыне классы ... это как писать ТЗ на готовую систему.
А здесь совсем ничего не понимаю.

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

iscrafm Shuhard1 для учетных систем - нет
2 нет
3 якобы - явная провокация,Вы же не лезете напрямую в БД sql.ru
4 опять провокация - структура БД не есть ведущий фактор обеспечения производительности
5 нет
1. почему это? учетным системам уже не нужны быстрые отчеты хотя-бы?
2. Можно пример?
3. Не конечно, не лезу... Речь не обо мне, а тогда уже о разработчике SQL.ru.. Он сначала интерфейс форума нарисовал, который под него БД сгенерил.. Или все таки создавал таблички, писал запросы, строил нужные индексы, а потом на ASP написал интерфейс.. может спросим?
4. хм... и чего все бьются над этими хитрыми схемами хранения данных?
5. Можно тогда пример, кроме 1С?

Привожу пример - приложения для Windows на C#. Сначала описываем предмет, его поведение, выделяем основные асбтрактные классы и интерфейсы. Пишем абстрактные классы и интерфейсы, потом уже пишем более детальные классы и имплементим интерфейсы. В любом случае начинаем не с методов.

В случае создания БД, переход от логики к физике такая рутина, что лично мне совершенно непонятно где там простор для творчества. Ну покажите что вы делаете такого, чего нельзя автоматизировать, ну хоть один пример.

mazzy gybsonВ случае создания БД, переход от логики к физике такая рутина, что лично мне совершенно непонятно где там простор для творчества. Ну покажите что вы делаете такого, чего нельзя автоматизировать, ну хоть один пример.
Два примера: 1) работа с глоссариями, 2) работа с онтологиями

"К сожалению, эффективная реализация объектной модели, независимая от конкретных СУБД, оказалась невозможной. В каждой СУБД некоторые действия производятся по-разному (например, создание уникальных ключей в таблице). Поэтому, в данный момент производится доработка кода JAVA-библиотеки, которая позволит работать с известными системами управления баз данных, и добавлять пользователям свои интерфейсы работ с различными СУБД. Это достигается вынесением в отдельный класс диалекта специфических операций для каждой системы баз данных. Для осуществления взаимодействия рассматриваемой библиотеки со специфическим пользовательским СУБД достаточно реализовать всего один JAVA-интерфейс.
Подводя итог, отметим то, что предлагаемый в данной работе меьлж хранения онтологий в реляционной базе и методы работы с ним являются универсальными, что позволяет широко использовать результаты предлагаемой работы в исследовательской и прикладной деятельности."

Ребята полным ходом идут к метаданным.

iscrafm gybson
Привожу пример - приложения для Windows на C#. Сначала описываем предмет, его поведение, выделяем основные асбтрактные классы и интерфейсы. Пишем абстрактные классы и интерфейсы, потом уже пишем более детальные классы и имплементим интерфейсы. В любом случае начинаем не с методов.
к чему этот оффтопик?

iscrafm
5. Можно тогда пример, кроме 1С?


Хоть бы помнили чего спрашиваете.