Python-сообщество

Давай дальше не будем друг-друга убеждать, что нет универсальных решений :D Мы и так это знаем :D

j2a
Давай дальше не будем друг-друга убеждать

ДАвай :) Хотя мой минимализм (см. ориджн) иногда оказывает мне медвежью услугу, тут я признаю. Но чаще он практичен.

balu
MSSQL … баги при большом файле журнала и приближении к концу 4 гиг

Хочу добавить об MSSQL личные наблюдения как раз по теме.
Делал проект на делфе, заказчику поставил базу с SQL Server Express. Предупредил об ограничениях, само собой, там админ немного разбирается, курсы прошел базовые. И вот после достижения максимального объема программа просто перестала писать добавлять новые документы в базу. При этом НИКАКОЙ ошибки не возникало. Смотрел трассировку запросов от клиента серверу - запрос выполнился, результат успешен, а записи в базе нет. И только запустив этот же запрос из-под Managenet Studio получил ошибку типа: нет места.

j2a
А ты код смотрел? Слабо такое же на raw sql и db api сделать? Потом сравним читабельность и объем кода.

Ну тогда уж нужно сравнвать полный код как генерируемого SQL, так и код библиотек вместе с собственным.

Лично я сторонник выносить логику в хранимые процедуры на сервер БД (хотя и не обязательно). Считаю, что на нынешнем этапе развития СУБД и железа необходимость в промежуточном звене отпадает. Кроме того, это самое промежуточное звено хорошо в определенных случаях: когда программист не знает SQL или проект небольшой или когда абсолютно точно известно, что не потребуется заниматься оптимизацией SQL-кода.
В больших проектах как правило есть отдельное звено - SQL-программист(-ы), программисту прикладному заранее известен набор (мета-) данных, которые получит его модуль (программа).
Есть много проектов (в особенности это касается web), которые требуют SQL-оптимизации.
В постоянных командах (фирма работает на себя, делает стартап, например) SQL-оптимизация делается первой, т.к. это быстрее и дешевле позволяет по сравнению с аппаратными решениями нарастить масштабируемость системы. Особенно это касается работы с большими объемами данных, которых поначалу просто нет и на этапе тестирования узкие места не выявляются. Если спросите, почему не выявляются, то ответ простой: тестовый сервер обычно сильно отличается от рабочего в худшую сторону - это раз и второе, что частично вытекает из первого - нет смысла генерировать тестовые данные на 3-5 лет вперед (по ряду причин) и тем самым получить такой объем данных, на котором вылезут узкие места.
Даже в банках тестовые базы ограничиваются периодом от полугода до 1,5 лет (в редких случаях, когда просто нужно посмотреть как система себя покажет на втором году работы).

ЗЫ
Не принимайте как начало холивара, плз. Переубеждать никого не собираюсь, да и меня переубедить врядли получится, т.к. я в своих суждениях исхожу из собственного опыта и стараюсь, не смотря на определенные рамки каждого проекта, заранее предусматривать разные неочевидные вещи.

Отредактировано (Май 15, 2009 16:31:18)

Пока я тут писал длинный пост, вижу уже пришли взаимопонимаю. :)

Lexander
Есть много проектов (в особенности это касается web), которые требуют SQL-оптимизации.

Для того же Firebird-a актуально - он не умеет толком паралелить запросы. И на приличных объемах приходится тюнить.

Lexander
Лично я сторонник выносить логику в хранимые процедуры на сервер БД (хотя и не обязательно). Считаю, что на нынешнем этапе развития СУБД и железа необходимость в промежуточном звене отпадает. Кроме того, это самое промежуточное звено хорошо в определенных случаях: когда программист не знает SQL или проект небольшой или когда абсолютно точно известно, что не потребуется заниматься оптимизацией SQL-кода.

А мне нравится использовать алхимовский ОРМ, практически вся логика в проектах вынесена в базу, запросы становяться простыми и тупыми, и ОРМ с ними прекрасно справляется, избавляя от кучи тупой работы.

ЗЫ: Никому не попадалось доки как включить установку postres в свой инсталятор? естественно, для “лучшей из операционок” ;)