Warning: Cannot use a scalar value as an array in /home/admin/public_html/forum/include/fm.class.php on line 757

Warning: Invalid argument supplied for foreach() in /home/admin/public_html/forum/include/fm.class.php on line 770

Warning: Invalid argument supplied for foreach() in /home/admin/public_html/forum/topic.php on line 737
Форумы портала PHP.SU :: Mysql PostgreSql PDO бекап [3]

 PHP.SU

 Программирование на PHP, MySQL и другие веб-технологии
PHP.SU Портал     На главную страницу форума Главная     Помощь Помощь     Поиск Поиск     Поиск Яндекс Поиск Яндекс     Вакансии  Пользователи Пользователи


 Страниц (4): « 1 2 [3] 4 »   

> Без описания
Поиск в теме | Версия для печати
OrmaJever
Отправлено: 26 Марта, 2016 - 21:45:34
Post Id



Активный участник


Покинул форум
Сообщений всего: 7540
Дата рег-ции: Янв. 2010  
Откуда: Чернигов


Помог: 299 раз(а)
3d_killer пишет:
но как тут можно вытащить все поля таблицы pre_core_group.*

Отдельным запросом


-----
Если вы хотя бы 3-4 раза не решите всё выкинуть и начать заново - вы явно что-то делаете не так.
 
 Top
MiksIr
Отправлено: 26 Марта, 2016 - 22:23:46
Post Id


Забанен


Покинул форум
Сообщений всего: 378
Дата рег-ции: Сент. 2014  


Помог: 10 раз(а)

[+]
Постгрес нынче умеет не требовать агрегатных функций при группировке по праймари ключу. Это и используй.


-----
self-banned
 
 Top
OrmaJever
Отправлено: 26 Марта, 2016 - 22:56:55
Post Id



Активный участник


Покинул форум
Сообщений всего: 7540
Дата рег-ции: Янв. 2010  
Откуда: Чернигов


Помог: 299 раз(а)
MiksIr постре не требудет агрегатных функций если в селекте только групируемое поле, это кстати не зависит от pk, но вот если нужно вытащить из таблицы что-то еще, кроме групируемого поля, а так зачастую и бывает, то нужно использовать агрегатные функции, после мускуля это очень не привычно и иногда даже странно, но это верно.


-----
Если вы хотя бы 3-4 раза не решите всё выкинуть и начать заново - вы явно что-то делаете не так.
 
 Top
MiksIr
Отправлено: 27 Марта, 2016 - 01:11:49
Post Id


Забанен


Покинул форум
Сообщений всего: 378
Дата рег-ции: Сент. 2014  


Помог: 10 раз(а)

[+]
OrmaJever
Если у нас джойн одной таблицы на другую, и группировка по первичному ключу одной из таблиц - поля этой таблицы можно использовать без агрегата

Цитата:
select p.name,count(c.*) from product p left join constants c on p.id=c.product_id group by p.id;


Достаточно давно такое работает.

(Отредактировано автором: 27 Марта, 2016 - 01:12:54)



-----
self-banned
 
 Top
3d_killer
Отправлено: 27 Марта, 2016 - 01:32:26
Post Id



Участник


Покинул форум
Сообщений всего: 1916
Дата рег-ции: Апр. 2011  
Откуда: Ростов-на-Дону


Помог: 21 раз(а)
да приходится некоторые фиксы писать, ну пофиг
PHP:
скопировать код в буфер обмена
  1.  
  2. public static function GetDateFormatNameBD()
  3.                         {
  4.                                 if(Base=='PostgreSQL'){return "to_char";}
  5.                                 if(Base=='MySQL'){return "DATE_FORMAT";}       
  6.                         }
  7.                 public static function GetDateFormat()
  8.                         {
  9.                                 if(Base=='PostgreSQL'){return "dd.Mon.YYYY";}
  10.                                 if(Base=='MySQL'){return "%d.%m.%Y";}                          
  11.                         }
  12.  
 
My status
 Top
OrmaJever
Отправлено: 27 Марта, 2016 - 12:38:00
Post Id



Активный участник


Покинул форум
Сообщений всего: 7540
Дата рег-ции: Янв. 2010  
Откуда: Чернигов


Помог: 299 раз(а)
3d_killer ой не, в коде нужно выбрать одну бд, если писать код и под мускуль и под постгрес то говнокод получится ибо иногда запросы сильно отличаются.
(Добавление)
MiksIr пишет:
группировка по первичному ключу одной из таблиц

Я сидел, думал, думал, а потом понял что группировка по первичкому ключу не имеет смысла, он ведь всегда уникален. То есть count каждой группы всегда будет 1. Поэтому таких запросов я просто не встречал и врядли встречу, но в остальных случаях нужно использовать агрегатные функции


-----
Если вы хотя бы 3-4 раза не решите всё выкинуть и начать заново - вы явно что-то делаете не так.
 
 Top
MiksIr
Отправлено: 27 Марта, 2016 - 13:50:32
Post Id


Забанен


Покинул форум
Сообщений всего: 378
Дата рег-ции: Сент. 2014  


Помог: 10 раз(а)

[+]
OrmaJever пишет:
Поэтому таких запросов я просто не встречал и врядли встречу,

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

(Отредактировано автором: 27 Марта, 2016 - 13:51:14)



-----
self-banned
 
 Top
armancho7777777 Супермодератор
Отправлено: 27 Марта, 2016 - 14:04:33
Post Id



Активный участник


Покинул форум
Сообщений всего: 4526
Дата рег-ции: Февр. 2011  
Откуда: Москва


Помог: 221 раз(а)
3d_killer пишет:
Соответственно, при запросах на выборку выходит очень много Left Join, на небольшом объеме данных все хорошо, но пробовал рендомно накидать объектов под 200 тыс, это превращается в ад, запросы по 15-30 секунд.

А может дело в самих запросах ?
На вскидку:
как поступит MySQL в случае с LEFT JOIN, а как в случае INNER JOIN ?
При грамотной архитектуре БД + грамотно составленных запросах, связывания отличные от INNER JOIN - крайне редко необходимы.
200т. для MySQL это много ? Серьёзно ?
Рекомендую, на прощанье с MySQL, открыть для себя (может, всё же, пригодится когда-нибудь) неплохую "книжку".

Касаемо различных СУБД: у каждой, в той или иной мере, свои сильные и слабые стороны.
Кроме самих данных и относительной структуры (лишь для ясности) ничего больше не нужно.

Тоже помаленьку осваиваю "Слоника".
Только не по причине проблем с производительностью I/O xxx тыс. записей...

(Отредактировано автором: 27 Марта, 2016 - 14:26:56)

 
 Top
3d_killer
Отправлено: 27 Марта, 2016 - 16:30:27
Post Id



Участник


Покинул форум
Сообщений всего: 1916
Дата рег-ции: Апр. 2011  
Откуда: Ростов-на-Дону


Помог: 21 раз(а)
armancho7777777 я не спорю для mysql это не много, просто помимо хотелось бы изучить и постгри и тут выяснились неприятности, то что привык делать так это по правилам построения запросов нельзя (не уверен, но возможно, что неправильное построение запросов влечет за собой лишние тормоза)
На данный момент я закончил с переходом и вобщем доволен, а именно проект может работать как на MYSQL так и на постгри
PHP:
скопировать код в буфер обмена
  1. define (Base,"PostgreSQL");
  2. //define (Base,"MySQL");

написал класс переноса таблиц и данных с mysql на постгри
чуть лучше стал знать постгри
Различий много:
получить последний id
PHP:
скопировать код в буфер обмена
  1. DB::DBH()->lastInsertId(PDB."adresat_directory_values_id_seq");

у PG вместо уникального индификатора выступают последовательности, нарушение которых дает возможность дублирования этих самых уникальных индификаторов что не приятно, сразу этого не узрел и после переноса при добавлении новых позиций база поехала, сначало не понял в чем дело, когда нашел пришлось дописывать в переносе текущий максимальный ID, так же PG ругается если пришел неверный формат данных, то есть надо все контролировать на уровне PHP, IF там нет!, но есть CASE который работает и в MYSQL
PHP:
скопировать код в буфер обмена
  1.  
  2. UPDATE rs_adresat_object_type_to_directory SET position=
  3. CASE
  4. WHEN position=".$pos." THEN ".$new."
  5.         ELSE ".$pos."
  7. WHERE position in(".$pos.",".$new.") AND type_id=:type
  8.  

лимиты через , указывать не правильно надо -
PHP:
скопировать код в буфер обмена
  1. LIMIT 50 OFFSET 0;

группировка и DISTINCT довольно требовательны к правильности построения.

В целом не жалею о полученном опыте, с Mysql конечно же не прощаюсь ибо много проектов работают на нем, на большей части хостов нет пока PG
(Добавление)
а и от кавычек удалось избавиться в названии таблиц удалив тот самый "-" в названии, теперь при смене подключения база сразу заводится хоть с PG хоть с MySQL
(Добавление)
armancho7777777 пишет:
как поступит MySQL в случае с LEFT JOIN, а как в случае INNER JOIN ?

это как бы разные вещи, данных по какому либо параметру может не быть, но в выборку объект попасть должен просто с этими параметрами NULL, INNER JOIN выкинет объект из выборки
(Добавление)
OrmaJever ну у меня в проекте кода который работает на постгри и при этом не работает на MySQL не оказалось помимо дат методы которые описывал выше
(Добавление)
может просто пока не было таких запросов

(Отредактировано автором: 27 Марта, 2016 - 16:34:24)

 
My status
 Top
OrmaJever
Отправлено: 27 Марта, 2016 - 16:51:20
Post Id



Активный участник


Покинул форум
Сообщений всего: 7540
Дата рег-ции: Янв. 2010  
Откуда: Чернигов


Помог: 299 раз(а)
MiksIr пишет:
Группировка по первичному ключу нужна для использования агрегатных функций в связанной таблице один-ко-многим. Я даже пример привел про это. Т.е., когда тебе, например, нужен юзер и число его коментариев - группировка по id юзера позволит достать его данные. Выглядит вполне логично, но долго время постгрес не давал это сделать.

А вот теперь я понял о чем ты. Да этот вариант очень даже не плох Улыбка
Я раньше подобные подсчеты делал вот так
CODE (SQL):
скопировать код в буфер обмена
  1. WITH c AS (SELECT count(*) count, user_id FROM comments GROUP BY user_id)
  2. SELECT u.id, COALESCE(c.count, 0) count
  3. FROM users u
  4. LEFT JOIN c
  5.         ON c.user_id = u.id

а твой вариант будет выглядеть так
CODE (SQL):
скопировать код в буфер обмена
  1. SELECT u.id, count(c.id) count
  2. FROM users u
  3. LEFT JOIN comments c
  4.         ON c.user_id = u.id
  5. GROUP BY u.id

Проверил експлеин, результат похож, время выполнения тоже примерно одинаковое. Спасибо за интересное решение Улыбка

(Отредактировано автором: 27 Марта, 2016 - 17:00:26)



-----
Если вы хотя бы 3-4 раза не решите всё выкинуть и начать заново - вы явно что-то делаете не так.
 
 Top
3d_killer
Отправлено: 27 Марта, 2016 - 17:03:59
Post Id



Участник


Покинул форум
Сообщений всего: 1916
Дата рег-ции: Апр. 2011  
Откуда: Ростов-на-Дону


Помог: 21 раз(а)
OrmaJever, ну вот вариат который ты привел первым так и описывается в документации, второй вариант я не видел и на сколько понял он используется в последних версиях PG, хотя он вполне логичен

(Отредактировано автором: 27 Марта, 2016 - 17:04:47)

 
My status
 Top
OrmaJever
Отправлено: 27 Марта, 2016 - 17:21:34
Post Id



Активный участник


Покинул форум
Сообщений всего: 7540
Дата рег-ции: Янв. 2010  
Откуда: Чернигов


Помог: 299 раз(а)
я только что попробовал несколько своих запросов переписать под групировку по PK, и результаты странные, где-то группировка по PK быстрее в 2 раза, где-то хуже в 10 раз. Так что тут надо смотреть по ситуации


-----
Если вы хотя бы 3-4 раза не решите всё выкинуть и начать заново - вы явно что-то делаете не так.
 
 Top
armancho7777777 Супермодератор
Отправлено: 27 Марта, 2016 - 19:26:15
Post Id



Активный участник


Покинул форум
Сообщений всего: 4526
Дата рег-ции: Февр. 2011  
Откуда: Москва


Помог: 221 раз(а)
3d_killer пишет:
это как бы разные вещи, данных по какому либо параметру может не быть, но в выборку объект попасть должен просто с этими параметрами NULL, INNER JOIN выкинет объект из выборки

Вопрос был не "Какой будет результат".
armancho7777777 пишет:
как поступит MySQL в случае с LEFT JOIN, а как в случае INNER JOIN ?

Перефразирую в лоб:
какой запрос выполнится быстрее ?
С LEFT JOIN или INNER JOIN, и почему ?
А так же: почему LEFT, а не INNER в Вашем случае ?
Потому как:
armancho7777777 пишет:
При грамотной архитектуре БД + грамотно составленных запросах, связывания отличные от INNER JOIN - крайне редко необходимы.

Уверен, у Вас не одного связывания через INNER.

(Отредактировано автором: 27 Марта, 2016 - 19:28:05)

 
 Top
3d_killer
Отправлено: 27 Марта, 2016 - 19:36:52
Post Id



Участник


Покинул форум
Сообщений всего: 1916
Дата рег-ции: Апр. 2011  
Откуда: Ростов-на-Дону


Помог: 21 раз(а)
почему же, когда выборка идет с параметрами то есть
PHP:
скопировать код в буфер обмена
  1. $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
(Добавление)
у меня таблица объектов, таблица типов объектов, таблица связи (тип - объект), таблица параметров, таблица с вариантами значений параметров (если тип параметра выбирается из списка) и таблица со значениями параметров или ссылками на них к конкретному объекту
 
My status
 Top
armancho7777777 Супермодератор
Отправлено: 27 Марта, 2016 - 19:47:17
Post Id



Активный участник


Покинул форум
Сообщений всего: 4526
Дата рег-ции: Февр. 2011  
Откуда: Москва


Помог: 221 раз(а)
Если правильно понял, у Вас там EAV-модель.
В MySQL 5.7 присутствует поддержка работы с JSON, что добавит возможность более удобно и оптимально, на мой взгляд, реализовать логику хранения данных.
 
 Top
Поиск в теме | Версия для печати
Страниц (4): « 1 2 [3] 4 »
Сейчас эту тему просматривают: 0 (гостей: 0, зарегистрированных: 0)
« SQL и Архитектура БД »


Все гости форума могут просматривать этот раздел.
Только зарегистрированные пользователи могут создавать новые темы в этом разделе.
Только зарегистрированные пользователи могут отвечать на сообщения в этом разделе.
  



Powered by PHP  Powered By MySQL  Powered by Nginx  Valid CSS  RSS

 
Powered by ExBB FM 1.0 RC1. InvisionExBB