Появилось немного времени решил попрактиковаться с БД Postgres
Работаю с PDO (с подключением проблем не возникло)
Бекап с Mysql развернуть я так понял не получится, синтаксис разный, как быть?
даже кавычки отличаются
если у mysql INSERT INTO `rs-cms_adresat_directory`
у постгри INSERT INTO "rs-cms_adresat_directory"
на что друг у друга конфликт, как делать универсальный бекап, как работают с этим другие программы например 1C, по созданию базы тоже синтаксис сильно разнится.
Кто сталкивался с подобным вопросом, как можно его решить?

тоже интересует
хотя подозреваю что разработчики слона просто смотрят на дельфинчика свысока
такое "фи"
хотя для оракла очень даже разработан портер
наверняка есть портер и для мускула
конечно без индексов
3d_killer индексы и партицирование и репликалиция
очень много отличий
скорее нет ответа
http://www[dot]youtube[dot]com/playlist?[dot][dot][dot]bZm-9-vKsi6vh5qC
рекомендую
вопросы думаю отпадут в виду понимания глупости самого вопроса
(Добавление)
Пысы: для последнего своего поекта выбрал дельфина
Причем самый некошерный myisam
Нифига не транзакционный
Нифига не реплицируемый
Но невероятно шустрый
Короче мораль в том что надо знать отличия
И выбирать зная

есть query builder'ы. Собстно прослойка для построения запросов а внутри для каждой БД свой класс для работы. И вам не нужно париться про отличия. Единственное sql-дампы для каждого типа БД свои.

Viper ыгым
Если забыть про то что слон любит скрипты внутри себя
Горизонтальное шардирование например
Нифига не тривиально

LIME, в том то и дело что о различиях я в курсе, последний проект я делал на MySQL, пока данных не много в нем, но ожидается прилично. Это база данных недвижимости, у каждого типа недвижимости куча свойств, они разные, соответственно сделаны эти свойства не полями. Соответственно, при запросах на выборку выходит очень много Left Join, на небольшом объеме данных все хорошо, но пробовал рендомно накидать объектов под 200 тыс, это превращается в ад, запросы по 15-30 секунд. Перевод в myisam базы немного повысил производительность, но недостаточно.
Недавно я задавал вопрос на форуме, по этому поводу, в итоге сделал таблицу memory дублирующую таблицу куда нацелены LEFT JOIN и триггером ее обновлял при добавлении или апдейте основной, то есть обновление и чтение конкретного объекта идет из основной, а выборка из Memory, поэтому начал смотреть в сторону postgresql, через Pgadmin собрал базу набил данными и пробовал запросы, работает намного быстрее, но вот с бекапом конечно вопрос интересный.
В принципе можно парсить и заменять ENGINE=InnoDB AUTO_INCREMENT=22 DEFAULT CHARSET=utf8 и т.д. на слова Pestresа, но если бекап огромный, как обработать столько данных, думаю, что как то таким образом и сделано например в 1С, так как постгри 1С поддерживать стала не так давно, кстати и не с любым работает для этого выпущен патч, то есть название примерно такое PostgreSQL 9.0.3-3.1C

Или ты намекиваешь на Orm?
(Добавление)
Вопрос вайперу
(Добавление)
УЖЕ ПЕРЕСТАЛ ЧИТАТЬ
капс случайно
значит юзай слона
самое то
и порт сам пиши
не все так просто как ты думаешь
для начала изучи что есть B-tree
дерево индексов в мускуле это все что надо знать
в слоне посложнее и погибче
(Добавление)
явно думай про Redis
(Добавление)
тут тебе и независимость от Storage
твой проект не должен зависеть от бд
критичные вещи не должны зависеть от субд
думай в этом направлении
разделяй и властвуй
это принцип построения кода если кто не понял
гуглить

Viper вот я и привел пример 1С, у нас файловая база или MSSQL неважно, зашли в программу выгрузили бд, это один файл потом создали на серваке подключение к постги, зашли в программу и развернули бекап с данными на нем, там не 2 внутри бекапа

3d_killer вот и я о чем
не надо критичные вещи решать на уровне субд
тогда и порт проще написатьбудет
я все сказал
удаляюсь

LIME вот я и думал про нерелятиционную базу, просто как бы не работал раньше с ними и пока не могу сказать про скорость выборки, а так же при применении нерелятиционной бд возможно использование ее частично, то есть данные что касаются обектов хранятся в редис все остальное в mysql

3d_killer дык вот в том и дело чтоб бд была только на выборку сохранение и ничего более
если конечно проект не диктует другого
а простого порта между субд не быавет... обычно
разрабы постгреса сделали порт для оракла
но это исключение
сделай так чтобы вызывать в проекте только методы сохранения/получения и ничего более
тогда и переходить на другой субд будет проще
хотя тут есть вопрос... с развитем проекта неизбежно возникает необходимость оптимизировать субд
и тогда становится сложнее поддерживать независимость
но одновременно становится понятнее какая субд более подходит
короче все сложно и поэтапно))

в той таблице уникальных индификаторов нет, вот мысли по редис тоже появлялись

сам посоветовал и сам предостергу
тут надо думать
усложнять проект и универсифицировать хранение или упрощать и зависеть от субд
универсального решения нет
зависит от проекта
короче нифига не тривиально

LIME понял что все сложно, буду думать, благодарю за советы

3d_killer поздравляю))
level up
это когда уже невозможно решать следуя гайдам из нета
придется разбираться ))
удачи

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