LINUX.ORG.RU
ФорумTalks

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

 


0

2

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

Вот перлы, которые там сплошь и рядом, больше всего доставило:

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

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

Ещё там зачем-то ввели свою реализацию биндингов переменных. Стандартная, работающая точно так же, чем-то не устроила.

Вот почему не делать так, чтобы везде работало? И зачем в мыскуле понаделывали такого бреда? Я был о них лучшего мнения.


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

drakmail ★★★★
()

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

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

staseg ★★★★★
()

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

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

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

vsemnazlo
()
Ответ на: комментарий от staseg

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

Удобно же

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

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

no-dashi ★★★★★
()

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

fjfalcon ★★★
()

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

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

KRoN73 ★★★★★
()
Ответ на: комментарий от no-dashi

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

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

KRoN73 ★★★★★
()
Ответ на: комментарий от no-dashi

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

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

shimon ★★★★★
()

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

r2d2
()
Ответ на: комментарий от no-dashi

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

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

Begemoth ★★★★★
()

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

yyk ★★★★★
()

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

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

gods-little-toy ★★★
()
Ответ на: комментарий от gods-little-toy

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

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

Saloed
() автор топика

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

snizovtsev ★★★★★
()
Ответ на: комментарий от Saloed

PostgreSQL.

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

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

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

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

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

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

gods-little-toy ★★★
()
Ответ на: комментарий от gods-little-toy

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

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

yyk ★★★★★
()

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

XVilka ★★★★★
()
Ответ на: комментарий от Begemoth

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

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

no-dashi ★★★★★
()
Ответ на: комментарий от staseg

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

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

praseodim ★★★★★
()
Ответ на: комментарий от true_admin

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

зачем?

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

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

Saloed
() автор топика
Ответ на: комментарий от true_admin

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

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

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

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

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

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

Saloed
() автор топика
Ответ на: комментарий от Saloed

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

true_admin ★★★★★
()
Ответ на: комментарий от true_admin

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

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

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

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

Saloed
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.