0. Браво, наконец-то появился очень политкорректный (все-таки удобнее вопросы проектирования, хотя бы логического, не смешивать с конкретной платформой, поскольку на них могут отвечать многие, не только те, кто интересуется MSSQL или Access) и правильный (ну и вообще ИТ-наукой доказано, что все-таки следует отделять "проектирование" от "программирования") раздел! Вот спасибо Администрации SQL.RU

1. Почему же только БД? Почему также не приложений? Ведь как правило (если пишется не только БД, а все) эти вещи очень сильно взаимосвязаны.

2. Почему же только проектирования ? Куда же делся анализ ? Ведь анализ и проектирование - это братья-близнецы и без первого не может быть второго! Да, до сих пор для многих в России это слово ассоциируется с некой непонятной и "ненужной" модно-заграничной фишкой. Но разработчики думающие так, сами и не подозревают, что вначале проекта они занимаются именно анализом, собирая сначала требования к своему приложению чтобы затем получить технический проект или ТЗ.

Может я чего не понял и название раздела ничего не значит, и меня зря "понесло", но все-таки... :))

3. Занимаемся ли мы проектированием или анализом, но также и не следует забывать о необходимом для этого инструментарии, а именно о CASE-средствах. Раз уж часто в разделах, посвященных MSSQL и др. СУБД обсуждаются всевозможные тулзы для работы с ними, то само собой, что в данном разделе будет неплохо обсуждать и CASE.

4. Поскольку я увидел, что пока нет описания к данному разделу, то позволю себе нескромно предложить (в случае принятия п.п.2,3):
"{ Обсуждение вопросов связанных с.. | Все вопросы по.. } системному анализу и проектированию БД и приложений, а также CASE технологиям и средствам"

5. Вот это Да! Какие только уже разделы ИТ не существуют у нас с Вами, дорогие друзья, на SQL.RU! А главное есть, есть специалисты готовые отвечать на вопросы страждущих

С наилучшими пожеланиями к Администрации ;)

2 wara:
Не знаю, прав я или нет, но эти самые CASE-средства позволяют просто "отобразить мысль", которая пришла к человеку на стадии анализа-проектирования. То есть человек сперва должен уметь анализировать и проектировать, а уж второй вопрос, с помощью чего можно отобразить его мысли. Поэтому не думаю, что уместно было бы в один и тот же раздел ставить эти два вопроса. Это как раздел "написание сценариев" совместить с разделом "правила использования печатной машинки" в каком-нибудь литературном форуме.

Может в литературном форуме это и было бы уместно, но надо все-таки учитывать особенности ИТ (действительно это Пушкину было бы все равно на чем набирать Онегина на компе или на машинке) и реалии. Так что на SQL.RU подобное ваше предложение равносильно предложению разбить раздел MSSQL на 3: "программирование под MSSQL", "администрирование MSSQL" и "программные средства для работы с MSSQL", что само по себе вообще-то глупо поскольку эти 3 предметных области очень сильно пересекаются за исключением некоторых случаев как вопросы чисто по TSQL, QA или правам пользователей. Так, например, у человека может возникнуть вопрос по анализу или проектированию, а при этом он будет использовать некое CASE-средство (такие вопросы далеко не редкость судя по другим форумам, посвященным анализу-проектированию и CASE, например, судя по тому же interface.ru к-рый просто разделен по CASE-продуктам фирм (хотя это больше в силу торгашеской ориентации этой конторы и ее форума)).
Как правило проблема может быть не только чисто методологического свойства или наоборот CASE-средство работает не так как нужно, она может иметь смешанный характер так что вопрошающему придется задавать один и тот же вопрос в 2-х разделах. (Пример такого вопроса: "Почему в Bpwin-е в модели нельзя создать 2 дочерние деятельности с одинаковыми именемами в разных в разных деятельностях ведь в жизни по смыслу это нормально...?")

И вообще следует поблагодарить проведение или свободное время или что там, что появилось у Администрации и позволило хотя бы проектирование БД выделить в отдельный раздел, хотя и здесь многие могут придраться ("а вот если я проектирую БД под MSSQL, там же есть свои особенности для физической модели?")