Как тузик грелку, надеюсь, рвет?
Адекватную настройку для майисам проводить перед тестом, я так понимаю, не надо. Иначе чего доброго грелка не порвется, тузика вырвет на асфальт.
В общем вы доказали что постгризом нормальный инженер пользоваться не будет. Ему нужна мера, а не крайности. Из меры складывается оценка КПД, а не из академических экспериментов.
Когда продукт хвалят за чудесные крайности - бегите от него подальше пока вас не зацепили багром за крайнюю плоть.
Крайности к мере никакого отношения. Тузик, то есть тазик, тоже может выжать 140. Что ж вы на субаре катаетесь?
Полная Версия: Класс работы с БД
дак наоборот, крайности у майисама: он рвет на запросах по первичному ключу, в остальном он ничего не рвет вроде))
ну блин, я не обсираю майисаму, я просто к тому что у всего есть свои плюсы, для проекта с сложными запросами я бы выбрал постгрес а не мускуль.
dr.nomore
Картинка пропадёт через 2 дня, так что смотри быстрее
_____________
Обучаю веб-программированию качественно и не дорого: http://school-php.com
Фрилансер, принимаю заказы: PHP, JS, AS (видео-чаты). Писать в ЛС (Личные сообщения на phpforum).
Картинка пропадёт через 2 дня, так что смотри быстрее
_____________
Обучаю веб-программированию качественно и не дорого: http://school-php.com
Фрилансер, принимаю заказы: PHP, JS, AS (видео-чаты). Писать в ЛС (Личные сообщения на phpforum).
| Цитата |
| он рвет на запросах по первичному ключу, в остальном он ничего не рвет вроде)) |
На попсовом сайте про примари так и написано each table must have at least one primary key или типа того.
Видите как все просто. Если религия не запрещает добавить такой ключ - майисам всех порвет.
Кстати, наконец я добрался посмотреть как устроен коннект и чтение у модного Yii. Структуру десятка типичных бд можно засосать через майсклю за те же ресурсы что расходуются в Джие на самый простой запрос.
inpost Можно и без пикселов, текстом. Давайте в применении посмотреть.
dr.nomore MiksIr
Мне как-то не интересно рассказывать детальные подробности моего основного проекта. Особенно когда на любую реализацию можно придумать альтернативное решение.
В любом случае применяю его для ON DUPLICATE UPDATE, собирает статистику по пользователю, с которой в дальнейшем работаю. На таблице в 300-400 тысяч. записей на нагруженном сервере - работает быстро.
_____________
Обучаю веб-программированию качественно и не дорого: http://school-php.com
Фрилансер, принимаю заказы: PHP, JS, AS (видео-чаты). Писать в ЛС (Личные сообщения на phpforum).
Мне как-то не интересно рассказывать детальные подробности моего основного проекта. Особенно когда на любую реализацию можно придумать альтернативное решение.
В любом случае применяю его для ON DUPLICATE UPDATE, собирает статистику по пользователю, с которой в дальнейшем работаю. На таблице в 300-400 тысяч. записей на нагруженном сервере - работает быстро.
_____________
Обучаю веб-программированию качественно и не дорого: http://school-php.com
Фрилансер, принимаю заказы: PHP, JS, AS (видео-чаты). Писать в ЛС (Личные сообщения на phpforum).
а мне нужен был по нескольким полям. Я не захотел создавать дубль.
_____________
Обучаю веб-программированию качественно и не дорого: http://school-php.com
Фрилансер, принимаю заказы: PHP, JS, AS (видео-чаты). Писать в ЛС (Личные сообщения на phpforum).
_____________
Обучаю веб-программированию качественно и не дорого: http://school-php.com
Фрилансер, принимаю заказы: PHP, JS, AS (видео-чаты). Писать в ЛС (Личные сообщения на phpforum).
| Цитата |
| ON DUPLICATE UPDATE |
Так вот если primary это unique key, то unique key не primary. Одновременно может быть и то и другое.
Я пытался представить что могло быть составным уникальным ключом. Например адрес. Город, улица, дом, квартира. По-отдельности все может повторяется и только комбинация должна быть уникальной.
Наличие отдельного primary не противоречит. Получив данные для записи вы делаете попытку вставить их. СУБД сама проверит уникальность, останется только запрограммировать вектор исключения. В режиме редактирования то же самое. Вы пытаетесь записать по примари, а СУБД проверяет по составному уникальному. Вектор прерывания по исключению тот же самый.
Разница между примари и уникальным ключем в том, что имя ограничителя (constraint) у примари всегда PRIMARY, а для всех остальных его надо придумывать или разрешать парсеру придумывать.
Разница между ограничителем PRIMARY и всеми остальными в том, что примари не может быть NULL, за счет чего оптимизация работает максимально эффективно.
Кстати, поэтому написав primary key атрибут not null можно умолчать. Парсер сам все сделает.
Но используя примари для отношений в ddl для референсед_колумн_нейм следует прописать явно not null и вообще сделать это поле копией типа примари без атрибутов примари и а_и Тогда гарантируется что связка пойдет по индексам.
Разница между ограничителем PRIMARY и всеми остальными в том, что примари не может быть NULL, за счет чего оптимизация работает максимально эффективно.
Кстати, поэтому написав primary key атрибут not null можно умолчать. Парсер сам все сделает.
Но используя примари для отношений в ddl для референсед_колумн_нейм следует прописать явно not null и вообще сделать это поле копией типа примари без атрибутов примари и а_и Тогда гарантируется что связка пойдет по индексам.
dr.nomore
Ты видишь мой Primary key и предлагаешь его заменить на unique. Покажи MySQL структуру таблицы + код через ON DUPLICATE UPDATE, чтобы работал по этому unique ключу. Иначе мне сложно будет понять твою мысль.
_____________
Обучаю веб-программированию качественно и не дорого: http://school-php.com
Фрилансер, принимаю заказы: PHP, JS, AS (видео-чаты). Писать в ЛС (Личные сообщения на phpforum).
Ты видишь мой Primary key и предлагаешь его заменить на unique. Покажи MySQL структуру таблицы + код через ON DUPLICATE UPDATE, чтобы работал по этому unique ключу. Иначе мне сложно будет понять твою мысль.
_____________
Обучаю веб-программированию качественно и не дорого: http://school-php.com
Фрилансер, принимаю заказы: PHP, JS, AS (видео-чаты). Писать в ЛС (Личные сообщения на phpforum).
Еще раз. ON DUPLICATE KEY UPDATE VALUES() вам потребуется только в частном случае. Когда вы заведомо знаете что делать в этой таблице, когда у нее какая-то особая рояль, когда вы хотите одним махом либо добавить новую запись, либо обновить НЕуникальные поля имеющейся.
Например такой таблицей может быть таблица конфига. Прилетела новая опция - добавилась. Прилетела старая - обновилась. Имя настройки уникальное, значение настройки меняется. Одним запросом вы оперируете весь конфиг не проверяя сперва есть такая запись - то обновить, нет такой записи - то добавить. Инструкция выше передается в СУБД и все проверки делаются там.
Такая таблица может быть встроена в рамку как служебная. Для нее не нужна модель, это системный компонент, dll.
В рамках общего применения вам вы ничего не проверяете, потому что СУБД по дефинициям сама все проверит и выкинет вам мессагу если проверка не прошла. Оператор не проверил есть ли такой клиент в БД? СУБД вашему скрипту скажет, а ваш скрипт переведет оператору: Нельзя делать дубликаты записей.
Насчет примари вообще. Я тут распинаюсь, понимаешь, а между тем есть такая приблуда как DAO где английским языком черным по белому написано
Please use for each table primary key and this column type must be int.
http://phpdao.com/
Например такой таблицей может быть таблица конфига. Прилетела новая опция - добавилась. Прилетела старая - обновилась. Имя настройки уникальное, значение настройки меняется. Одним запросом вы оперируете весь конфиг не проверяя сперва есть такая запись - то обновить, нет такой записи - то добавить. Инструкция выше передается в СУБД и все проверки делаются там.
Такая таблица может быть встроена в рамку как служебная. Для нее не нужна модель, это системный компонент, dll.
В рамках общего применения вам вы ничего не проверяете, потому что СУБД по дефинициям сама все проверит и выкинет вам мессагу если проверка не прошла. Оператор не проверил есть ли такой клиент в БД? СУБД вашему скрипту скажет, а ваш скрипт переведет оператору: Нельзя делать дубликаты записей.
Насчет примари вообще. Я тут распинаюсь, понимаешь, а между тем есть такая приблуда как DAO где английским языком черным по белому написано
Please use for each table primary key and this column type must be int.
http://phpdao.com/
Если вы сделаете авто-обновление через on duplicate key update для рабочей таблицы, получится вот что. Оператор думает что добавляет новый товар, или нового клиента, а на самом деле ничего не добавляет, а только обновляет данные о старом товаре, о прежнем клиенте.
Это не допустимо. Только особые, заведомые случаи могут найти применение в этой технологии.
Это не допустимо. Только особые, заведомые случаи могут найти применение в этой технологии.
Здесь расположена полная версия этой страницы.