Как писать SQL-совместимый код?

[Духовность™]

Как писать SQL-совместимый код?

Пишу SQL всегда под конкретную базу - MySQl. Других СУБД я в глаза не видел и с ними не работал.
Имеет ли смысл писать SQL по стандарту для совместимости с другими СУБД и, если да, то как следовать этому стандарту? Есть ли какие-то "шпаргалки"/мануалы, позволяющие проверять валидность кода?

 

[HraKK]

Никак. Не имеет. Нету.

 

[Духовность™]

Почему не имеет?

 

[Single]

Имеет ли смысл писать SQL по стандарту для совместимости с другими СУБД

а попробуй писать SQL для mySql и msSql одновременно, "сюрпризы" не заставят себя долго ждать.

 

[Духовность™]

я и спрашиваю - как писать максимально совместимый код? или это невозможно?

 

[HraKK]

Никак. Нет.

 

[Духовность™]

понятно.

 

[Krishna]

как писать максимально совместимый код? или это невозможно?

http://www.doctrine-project.org/

 

[whirlwind]

triumvirat SQL92 + креоловские драйверы

 

[Krishna]

Имеет ли смысл писать SQL по стандарту для совместимости с другими СУБД

Имеет, с целью повышения собственной культуры (что облегчит возможные миграции на другие базы в будущем не проекта, но тебя) и читаемости кода для других программистов. А именно для переносимости - ORM.

Есть ли какие-то "шпаргалки"/мануалы, позволяющие проверять валидность кода?

http://dev.mysql.com/doc/refman/5.5/en/server-sql-mode.html

 

[HraKK]

>Имеет, с целью повышения собственной культуры
Как по мне искусственное ограничение инструмента, это деградация а не развитие. Но Вам конечно виднее.

>читаемости кода для других программистов
Знать разные SQL диалекты и писать универсальное не есть тождество. Но Вам опять же виднее.

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

 

[AmdY]

ага, только последние тенденции показывают, что переходить вероятнее придётся с SQL на NoSQL

 

[Farsh]

Автор оригинала: Krishna
http://www.doctrine-project.org/

+1. В symfony 2.0 будет 100%-ое покрытие тестами mysql, pgsql, oracle. А больше ничего и не надо, вроде -)

 

[zerkms]

AmdY
тенденции имеют место быть только для оооооочень нагруженных проектов, для которых переход разумный и оправданный. даже тот же Калахан говорит, что в связи с популяризацией SSD - мотивировать переход на NoSQL будет оооооочень сложно.

у обычных смертных же и без NoSQL остаётся большой запас для роста и оптимизаций.

мой вердикт: переход на NoSQL или понты, или поиск панацеи. исключение (ооооочень редкое) - когда ни то, ни другое

-~{}~ 27.04.10 00:42:

100%-ое покрытие тестами

омг %) не флейма ради - но это:
1. невозможно
2. не имеет смысла

 

[HraKK]

1. невозможно

Значит тесты пишут русские. А у них

невозможное возможно©АвтоВАЗ

 

[Lightning]

zerkms
Это почему 100% покрытие тестами невозможно?

 

[Farsh]

Автор оригинала: zerkms
омг %) не флейма ради - но это:
1. невозможно
2. не имеет смысла

Верней, хотел сказать, что полное тестирование, при котором можно будет безбоязненно мигрировать на этих трех БД.
А вообще, было бы круто, если бы еще имплементировали sqlsrv драйвер.

 

[Fortop]

я и спрашиваю - как писать максимально совместимый код? или это невозможно?

Не удалятся за

[sql]SELECT * FROM sometable WHERE somecondition ORDER BY somecolumn[/sql]

• не использовать "странные" символы в названиях полей
• не использовать названия, которые возможно зарезервированы в какой-либо БД
• не использовать функции, конструкты и подзапросы.

При этом LIMIT, GROUP, JOIN в большинстве случаев будут работать, но не всегда.

Но надо ли это?

P.S. Еще, как действительно реальная альтернатива - хранить SQL код в БД (хранимые процедуры), тогда задача DBAL в приложении будет лишь в замене
[sql]EXEC procname()[/sql]
на
[sql]CALL procname()[/sql]

 

[fixxxer]

Особенно хорошо эта альтернатива будет работать в мыскле, где все хранимки тупо каждый раз парсятся и интерпретируются, гы-гы. Не, ну с другой стороны, если такая задача стоит, то на производительность давно положено, да.

 

[Lightning]

Еще, как действительно реальная альтернатива - хранить SQL код в БД (хранимые процедуры), тогда задача DBAL в приложении будет лишь в замене
SQL:

А код самих процедур менять?

Кроме того, при таком подходе возникают проблемы с контролем версий и диплойментом. И часть бизнес-логики попадает в БД. Тогда уж лучше всю бизнес-логику переносить в БД. Но в таком случае, при миграции нужно будет переписывать больше кода. Короче, не вариант.

-~{}~ 26.04.10 22:20:

Имеет ли смысл писать SQL по стандарту для совместимости с другими СУБД

ИМХО, не имеет.

Как насчет SQL-билдера?