$query.=" INNER JOIN ".PDB."core_group_to_user ON ".PDB."core_group_to_user.id_user=".PDB."core_users.id AND ".PDB."core_group_to_user.id_group = :group";
а параметры вытаскиваются для вывода через LEFT (Добавление)
у меня таблица объектов, таблица типов объектов, таблица связи (тип - объект), таблица параметров, таблица с вариантами значений параметров (если тип параметра выбирается из списка) и таблица со значениями параметров или ссылками на них к конкретному объекту
OrmaJever, ну вот вариат который ты привел первым так и описывается в документации, второй вариант я не видел и на сколько понял он используется в последних версиях PG, хотя он вполне логичен
armancho7777777 я не спорю для mysql это не много, просто помимо хотелось бы изучить и постгри и тут выяснились неприятности, то что привык делать так это по правилам построения запросов нельзя (не уверен, но возможно, что неправильное построение запросов влечет за собой лишние тормоза)
На данный момент я закончил с переходом и вобщем доволен, а именно проект может работать как на MYSQL так и на постгри
у PG вместо уникального индификатора выступают последовательности, нарушение которых дает возможность дублирования этих самых уникальных индификаторов что не приятно, сразу этого не узрел и после переноса при добавлении новых позиций база поехала, сначало не понял в чем дело, когда нашел пришлось дописывать в переносе текущий максимальный ID, так же PG ругается если пришел неверный формат данных, то есть надо все контролировать на уровне PHP, IF там нет!, но есть CASE который работает и в MYSQL
группировка и DISTINCT довольно требовательны к правильности построения.
В целом не жалею о полученном опыте, с Mysql конечно же не прощаюсь ибо много проектов работают на нем, на большей части хостов нет пока PG (Добавление)
а и от кавычек удалось избавиться в названии таблиц удалив тот самый "-" в названии, теперь при смене подключения база сразу заводится хоть с PG хоть с MySQL (Добавление)
armancho7777777 пишет:
как поступит MySQL в случае с LEFT JOIN, а как в случае INNER JOIN ?
это как бы разные вещи, данных по какому либо параметру может не быть, но в выборку объект попасть должен просто с этими параметрами NULL, INNER JOIN выкинет объект из выборки (Добавление) OrmaJever ну у меня в проекте кода который работает на постгри и при этом не работает на MySQL не оказалось помимо дат методы которые описывал выше (Добавление)
может просто пока не было таких запросов
ну да сейчас меняю, перебил таблички убрал "-", потихоньку поднимается, надо проверить около 500 операций (Добавление)
вот не пойму только, написал перенос, все что касается дат, не могу вставить пустую дату в постгри так сделать нельзя? (Добавление)
а так вобщем большая часть работоспособна, единственное LIMIT OFFSET через запятую было да и с группировкой надо использовать DISTINCT
$STH= DB::DBH()->prepare("SELECT * FROM \"".PDB."core_constant\"");
не менять же весь код, PDO же для чего сделано, но ответа я не нашел, кто мигрировал как тут быть? (Добавление)
без кавычек никак, так как в названиях таблиц присутствует "-"
я не про хенкока, а про дедпула.
А то что все сложнее понятно бывает, на прошлой работе база 300 гигов была но на MsSQL там о таких вещах говорить намного сложнее, но сейчас разговор о меньших данных, но все же (Добавление)
Главная
Помощь
Поиск
Пользователи
Найдено сообщений: 1914
