Для серьезных проектов приоритеты другие

1. открытость /масштабируемость/
2. переносимость
3. модифицируемость /развитие и поддержка/

По этим критериям - конечно, MS SQL

2 kiled
Обоснование некоторых утверждений требует
большого времени и места.
Я как-то раз только начал предисловие
к одному обсуждению - было предложение его
закрыть :)
Если есть интерес к серьезному разговору,
думаю, можно общаться по почте - мой адрес
DKObmen@newmail.ru

P.S. Кстати, меня зовут Дмитрий
С MS работаю с 1995 г,
3 года работал с Oracle
в It с 1976 г. :) - есть основания для
уверенности в некоторых выводах :)

Я уже говорил.
Писать очень много...
Только начал подбираться к такой теме,
народ просил закрыть обсуждение
/я всего то начал говорить с Zaxx-ом /

2 killed

Я, пожалуй, попробую кратко ответить на вопросы

1. что такое открытость?
Открытость определяется не инструментарием,
а "подчерком" разработки - из предлагаемых
баз по ряду причин /объективных и субъективных/
открытая разработка удобнее реализуется на MS
2. Что такое переносимость?
Разработка таким образом, что проект с минимальными
затратами переходит на другую СУБД, платформу и
т.п. Определяет то же, в основном, способом
разработки..
В наших проектах чаще всего встречалась миграция
MS-Oracle /лет 7 назад были и настольные, типа
Paradox, DBase и пр. /
3. Что такое серьезный проект? Его бюджет?
Для нас серьезный проект - время разработки несколько
человеко-лет /от 1 до 5/, время жизни 5 и более лет
Бюджет разработки и внедрения от 25 - 30 KUSD,
стоимость самой разработки /без техники, обучения,
сопровождения, доп персонала и т.п./ мимнимум 7-10 K$

2 killed
Эдвард /если не ошибаюсь :)/

Я, кстати, взглянул - в том обсуждении
именно ты и предлагал положить ссылку
на исходники и закрыть тему

2killed /Кстати, предлагаю на "ты"/

Совершенно согласен с разграничением
понятий открытости - как способа разработки,
и как юридические /правовые/ проблемы..

Конечно, я веду речь только о первом.
Что касается такой "открытой" разработки,
то существую принципы, которые позволяют
находить приемлимые решения между
открытостью /изменяемость, переносимость и т.п./
и "использованием полезных фич"...
Хотя, конечно, идеал здесь вряд ли достижим...
Другое дело, что чем дальше, тем больше
приоритеты смещаются в сторону первого :)

О том, собственно и шел разговор :)..

Кстати, неужели сейчас где-то актуальны правовые
проблемы для разработки проектов? :)

И в догонку...
Исходники выложить конечно, не жалко
/хотя кое-что, пожалуй и не стоит по
различным причинам/...

Но вряд ли кто то эффективно может
работать с десятками тысяч строк
чужого текста по неизвестным принципам :)

И еще раз в догонку...

Удобство MS именно и состоит в некоторых
фичах /самая приятная - временные таблицы/,
позволяющих проще и эффективнее реализовывать
принципы открытой разработки /хотя мы и на
Oracle писали нечто похожее :)/

Может, не стоит так уж сразу отбрасывать
и субъективные причины?

Ведь, они часто оборачиваются объективными
плюсами

- возможность использования старых наработок
- более продуманная документация и сопровождение
- обучаемость

и т.п.

2Е.А.Загоруйко
Конечно, постановка задачи - основное.
Но с твоим подходом оценка стоимости
проекта (как, похоже и сам проект)
явно будет полна лажа .... :)

2ASCRUS
Попробую показать на примере :)

Мне надо сделать интерфейс обработки объекта..
При этом заранее неизвестно ни
число параметров, ни их тип
/например, я готовлю отчет по прсроченной
дебиторской задолженности, мне нужен
универсальный обработчик, ктр постоянно будет
изменяться и выдавать поток данных по различным
срокам, видам оплат и т.п./

Для открытой разработки важно, чтобы этот интерфейс
мог модифицироваться без изменения всех остальных
модулей, ктр с ним взаимодействуют ...

Стандартное решение - пишется заглушка, ктр
выдает сначала всю дебиторку...
Через неделю нужно выделить только дебиторку
менеджера Иванова.
Есть 3 задачи
1. где-то в клиенте выбрать параметр - менеджер
и занести значение Иванов
2. передать это значение обработчику /в простейшем
случае ХП/
3. дописать обработчик

При решении "в лоб" - надо модифицировать и
перетранслировать все модули, вкл клиента...

"Открытый" подход состоит в том, что где-то в стороне
есть отдельный кусок, в ктр организован выбор
параметра /модификация этого куска не затрагивает
остальные части клиента!/.
Куда-то значение этого параметра надо засовывать, чтобы ротом анализировать в обработчике.
Стандартное решение - создать таблицу, где хранятся эти параметры и их значения.
Просто таблица код параметра - значение приведет
к конфликтам /один выбрал Пупкина, другой в то же время- Васькина/. Причем, даже анализ логина / по аналогу временных таблиц в Oracle/ не решает проблему - может быть запущено несколько клиентов /в т.ч. различных приложений/, ктр будут мешать друг другу.
Использование временных таблиц позволяет организовать независимое и развиваемое (!!!) взаимодействие различных модулей и передачу параметров между ними.

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

Это - наиболее очевидное преимущество /хотя, пожалуй,
не единтсвенное и даже, наверное, не самое главное :)/

2Zaxx
Возможно...
Поскольку я уже года 2 не имел дела
с Oracle, может, я просто этого и не знаю.
По приведенному тексту похоже, что так оно и есть ...

2Ora600
Не передергивайте...
Я утверждал, что MS SQL удобнее с моей точки зрения
Это естественно, поскольку я имел с ним дела в 2-3
раза дольше, чем с Oracle /не говоря уже о том,
что Oracle намного больше и сложнее MS/..

Что касается вопорса насчет программист ли я?
Он звучит более чем странно...
Суди сам
- Любой проект начинается с постановки,
естественно, основное внимание уделяется
предметной области, ее законам и функционированию
Следующее по приоритету - технология разработки,
возможность создавать модульные проекты, легко
изменяемые и переносимые.
Технические вопросы, в т.ч. "кишки СУБД" при таком
/думаю, оправданном :)/ подходе имеют
третьестепенное значение.
В этом случае, вполне возможно, что некоторых
особенностей я и не знаю /до сих пор много интересного
и нового нахожу на форумах MS и Delphi/...
Не правда ли, такой подход практичнее, чем
разбираться в инструментарии "до самых винтиков"
/тем более, что на моей памяти с 1986 г эти
инчструментарии меняются с бешенной скоростью :)/

Не горячись, Ora600....
Успокойся..
Как раз в отм и дело, что я все это время
решал конкретный задачи и строил эффективные
системы, а не возился с инструментарием...

Думаю, форум и есть место для обсуждения разных точек зрения... Есть сермяга и в том, что первична,
все же постановка задачи /она решает сильно много/, бывали и ошибки, связанные с недостаточным знанием инструментария /кстати, благодарен Zaxx-y за временные таблицы в Oracle, думаю, будет возможность еще проверить/.
А ситуация чаще наоборот - есть люди, решающие реальные проблемы /например, тот же биллинг/, а есть техники, ктр ковырются в железяках. Первые без вторых, может не всегда найдут самый оптимальный путь, зато вторые без первых вообще никому не нужны :)...

Вдогонку to Ora600
Кстати, сам очень недолюбливаю SAP ...

Нет, Эдвард,
за сильную жесткость и громоздкость :)
Была пара задач /до проектов не дошли ../
То, что там предлагалось сделать на R3,
мы уже эффективнее делали раньше /правдо,
по большей части в рамка интеграции .../