Comments 11
Ещё одна причина пользоваться хэлперами для бд, как при создании, так и при запросах к таблице.
Можете сказать, что вы подразумеваете под хэлперами и чем они помогут при переносе?
Практически для каждого языка программирования существуют хэлперы для работы с БД. Они позволяют вместо написания sql запросов писать на ЯП, при чем, в настройках хэлпера можно указать тип бд, а он в свою очередь уже будет генерировать запрос в зависимости от синтаксиса. Пример
В случае хелпера это может выглядить следующим образом
Вот что касается переноса, они ни чем не помогут, просто в случае переноса, не надо переписывать кучу запросов. Просто есть яркий пример миграции с одной бд на другую, и им пришлось переписывать кучу запросов.
SELECT * FROM TABLE WHERE ATTR1>1 LIMIT 0, 10
SELECT TOP 10 * FROM TABLE WHERE ATTR1>1
SELECT * FROM TABLE WHERE ARRT1>1 and ROWNUM<=10
В случае хелпера это может выглядить следующим образом
var sql = helper("mssql").select("*").from("table").where("attr1>1").limit("10")
Вот что касается переноса, они ни чем не помогут, просто в случае переноса, не надо переписывать кучу запросов. Просто есть яркий пример миграции с одной бд на другую, и им пришлось переписывать кучу запросов.
По текущему опыту переноса относительно крупного проекта могу сказать, что переписывать кучу запросов не пришлось, а в тех случаях где пришлось хэлпер бы не помог. Встретил лишь два типа проблем или отсутствующие функции (nvl, to_number) или работа с boolean.
Есть еще некоторое число больших сложных отчетов, где могут возникнуть проблемы, но их писать в хэлпере не удобно. Sql на 200-500 в подобном виде практически не читаемы и их труднее отлаживать.
Есть еще некоторое число больших сложных отчетов, где могут возникнуть проблемы, но их писать в хэлпере не удобно. Sql на 200-500 в подобном виде практически не читаемы и их труднее отлаживать.
sql на 200-500 в принципе не очень читабельны ) Но что поделать. Я после приведенного выше примера с переписыванием кучи sql придерживаюсь мнения что лучше писать запросы через хэлперы.
Все зависит от того как писать, если использовать конструкцию with и бить на куски, то 500 строчек sql разбиваются на десяток относительно простых, понятных и легких запросов. Которые можно отлаживать последовательно друг за другом. Не самое приятное дело, но и ничего титанического в этом нет.
Касательно лимита по числу строк, у нас в проекте используется hibernate + нативные запросы через него и именно этот тонкий вопрос различий БД удалось обойти, но можно ли считать его хэлпером )
Касательно лимита по числу строк, у нас в проекте используется hibernate + нативные запросы через него и именно этот тонкий вопрос различий БД удалось обойти, но можно ли считать его хэлпером )
Спасибо, мне понравилось.
Ещё, если интересно, можно вот здесь посмотреть (вдруг, что полезное найдётся):
www.sqlines.com/home
www.sqlines.com/oracle-to-postgresql
Ещё, если интересно, можно вот здесь посмотреть (вдруг, что полезное найдётся):
www.sqlines.com/home
www.sqlines.com/oracle-to-postgresql
Похоже, что переход с Oracle на Postgres становится массовым. Еще заметил, что не менее массово проекты переносят с Hadoop/Hive/Spark на тот же Postgres.
Разве nvl не заменяется элементарно с помощью coalesce?..
Sign up to leave a comment.
Полезные скрипты при миграции из Oracle в PostgreSQL