[МыSQL][стандарты]Негодования тред

Ну так быдлокодить можно и под постгрес. Правда, простор для быдлокода несколько меньше, соглашусь )

INSERT INTO table SET field1=", field2=". // Убить бы.

Удобно же. На мускуле всегда им пользуюсь. Это не нарушение SQL, а расширение. При переходе на MSSQL тоже пришлось почертыхаться.

* UPDATE table SET field1=", field2=" WHERE primary_key=value LIMIT 1 // ** Ну зачем, ЗАЧЕМ?

Для тестирования.

Вам известны СУБД, полностью соответствующая стандарту?

> INSERT INTO table SET field1=", field2=". // Убить бы.

Удобно же

Удобно - это когда потом не надо переделывать.

Поэтому insert into table(field1,field2) values (",") удобней.

ORM все таки не зря придумали.

INSERT INTO table SET field1=", field2=". // Убить бы

При ручном составлении запросов ОЧЕНЬ удобно. Не приходится ручками считать соответствие столбцов и значений.

Удобно - это когда потом не надо переделывать.

А для этого уже ORM есть.

Удобно - это когда потом не надо переделывать.

Я что-то не припомню проектов, ВНЕЗАПНО мигрирующих на другую РСУБД (и поэтому считаю проблему абстракции БД откровенно надуманной). Даже в случае MySQL люди будут плакать, колоться, придумывать лекарства для языка, но будут жрать кактус, однажды подсев на него.

Ты ещё GCC и glibc поковыряй на тему расширений ;-)

Поэтому insert into table(field1,field2) values (",") удобней.

Я правильно понимаю, что таблицы с большим количеством полей не попадаются?

напиши транслятор из одного в другое. делов-то

Переделываю один интернет-магазинчик, чтобы он работал на PostgreSQL. Изначально он был, естесственно, на мыскуле. Т.к. с последним я особо и не работал, был очень сильно удивлён, а потом и разозлён, насколько же оно не соответствует стандарту SQL.

А ты чего думал? Покажи хоть одну субд, соответствующую этому вашему стандарту SQL. Особенно если приходится выйти за пределы лабораторной работы №1 курса «введение в базы данных»...

А ты чего думал? Покажи хоть одну субд, соответствующую этому вашему стандарту SQL

PostgreSQL. Расширения стандарта есть у всех, но объясните мне, НУ НАХРЕНА при аптейте ПО ПРИМАРИ КЕЙ делать LIMIT 1? И вообще нахрена лимит в апдейтах? Руки за такое отрывать надо.

При переходе на MSSQL

Омг, ЗАЧЕМ?

Это что, мне вот приходится для курсовой допиливать быдлокод на питоне, написанный до этого другим студентом. Вместо импортов там частенько используется метод добавления переменных в __builtin__.__dict__, название переменных вроде megastore, aso (несколько человек работает с этим кодом, и никто не знает, что это), отсутвие или 0 полезность комментариев, месево из deepcopy, кривая попытка придание общей архитектуры повсеместно фиксится «HACK-ами». И такого кода несколько тысяч строк. Вывод pylint не сильно меньше размера кода.

PostgreSQL.

И что там, например, partitioning соответствует стандарту? Вместо него вообще какое-то «наследование таблиц» - нету в стандарте такой концепции..

А c «LIMIT 1» чего? В стандарте этого нету, почему постгрес это поддерживает?

Расширения стандарта есть у всех, но объясните мне, НУ НАХРЕНА при аптейте ПО ПРИМАРИ КЕЙ делать LIMIT 1?

это ты к СУБД претензию предъявляешь? Спрашивай тех, кто твое приложение написал.

И вообще нахрена лимит в апдейтах? Руки за такое отрывать надо.

Не понял темы. как без LIMIT сформулировать действия типа «поставить 10 наиболее задолжавшим клиентам статус заблокирован» одним запросом?

как без LIMIT сформулировать действия типа «поставить 10 наиболее задолжавшим клиентам статус заблокирован» одним запросом?

За такие формулировки надо «менеджерам» головы отрывать, блокировать по сумме задолженности старше некоторого периода.

полностью поддерживаю. Даже в MediaWiki, c заявленой поддержкой PostgreSQL, постоянно приходиться косяки разгребать, базу править, и т.д. и т.п. Нет, чтобы ORM или фреймворк готовый использовать.

Я правильно понимаю, что таблицы с большим количеством полей не попадаются?

Ты неправильно понимаешь, потому что все нормальные люди пишут insert into table(field1,field2) values (:field1,:field2) и потом по именам подвязывают значения к параметрам при вызове запроса.

Омг, ЗАЧЕМ?

У заказчиков есть специалисты только по MSSQL и виндам, выполняем их каприз.

У заказчиков есть специалисты только по MSSQL и виндам, выполняем их каприз.

Это не специалисты, а обезьянки. Дрессированные на технологии конкретной фирмы.

Переделываю один интернет-магазинчик

зачем?

Переделываю один интернет-магазинчик

зачем?

Чтобы работал на PostgreSQL.

Всегда ваш, Капитан Очевидность.

в чём выражается преимущество постгреса для инет-магазина?

в чём выражается преимущество постгреса для инет-магазина?

В том, что мне надо не один раз поставить и забыть, мне допилить под себя нужно, и допилить основательно. Мыскуль, мягко говоря, убог, такая себе записная книжечка, ничего кроме тупого селекта (никаких джоинов! НИКАКИХ!!!) апдейта и инсерта не умеющая.

Поэтому для меня и в данном случае преимущества такие:

1) В удобстве (лично для меня) в плане допиливания нужных мне фич, в т.ч. и учётно-статистических (а мыскуль на запросах сложнее SELECT * FROM table LIMIT 10 тупо дохнет)

2) В возможности нормальной интеграции с учётно-бухгалтерской системой (Дебет-Плюс) - см.п.3

3) В возможности вообще нормальной интеграции с движками блогов/форумов/ещё чего угодно - благодаря наличию в постгресе тех же вьюх и триггеров.

окей, пунктом 2 убедил, но вот про join-ы можно по-подробнее? Что значит «никаких джоинов»? Джоины там есть. Вьюхи и триггеры тоже (верю что в постгресе возможностей больше).

join-ы можно по-подробнее? Что значит «никаких джоинов»? Джоины там есть.

Есть, только они... Хм... Слегка неработоспособные.

Пример. Пришлось один раз перегонять данные с мыскуля в тот же постгрес с небольшим изменением структуры. Из мыскуля - селект из таблицы ~~60 колонок и ~~20000 строк, INNER JOIN двух таблиц (1000-10000строк). Мыскуль выполнял запрос минуты две.

Да и вообще, более-менее сложные запросы (с теми же джоинами, когда их много, подзапросами, вызовами функций и т.д.) и мыскуль несмовестимы. Встроенных языков для хранимок нет, поэтому с триггерами вообще не ясно - а как их писать? Вьюхи - обновляемые вьюхи есть? А для интеграции с той же учёткой могут пригодиться.

понятно, спасибо за разъяснения.