Рубрики статей

[Andkorol]

Я использую 4-ю,самую новую версию.
Даже создал для неё отдельную Базу Данных, с "чистым" вашим дампом.
Связи теряются, всё работает так,как я описал выше.
Т.е. после переименования Категории - не происходит изменение значений в записях статей.

Это - проблема,и серьёзный недостаток.

PS:

Я только, что проделал данные операции с переименованием и поиском, проверил данные в базе - всё верно.

Как всё может быть "верно" - если у вас просто нет такого кода,который бы занимался синхронизацией записей в таблице с изменёнными названиями Категорий.
Этого в вашем коде просто НЕТ.
Если же я вдруг ошибаюсь(слеп,глуп и т.д. - такое бывает) - выложите,пожалуйста, данный код прямо в сообщении,с указанием файла,в котором он расположен, и версии скриптов.
Спасибо!

[Виталий Желтяков]

Во-первых, ссылка на видео-демонстрацию работы - демонстрация

у вас просто нет такого кода,который бы занимался синхронизацией записей в таблице с изменёнными названиями Категорий

А он и не нужен. Если всё работает правильно то откуда взяться ошибкам в БД.

[Andkorol]

Сообщение от Виталий Желтяков

А он и не нужен. Если всё работает правильно то откуда взяться ошибкам в БД.

Ну супер просто - уличная магия изменяет значения в записях???

[Andkorol]

Провёл небольшой эксперимент(на что толкнуло ваше бодрое видео) - решил поэкспериментировать с версиями ПО,благо наличие нескольких компов и ОС это позволяют...

Рад вам сообщить,что корректно проблема синхронизации решается далеко не на любом установленном ПО.
Например, вот на такой конфигурации всё работает корректно:

MySQL
Server: MySQL host info: localhost via TCP/IP
Server version: 5.1.40-community
Protocol version: 10
User: *****@localhost
MySQL charset: UTF-8 Unicode (utf8)
Web server
Apache/2.2.4 (Win32) mod_ssl/2.2.4 OpenSSL/0.9.8k PHP/5.3.1
MySQL client version: mysqlnd 5.0.5-dev - 081106 - $Revision: 289630 $
PHP extension: mysql

А вот на более новой конфигурации - уже не работает:

MySQL
Server: localhost via TCP/IP
Server version: 5.1.47-community
Protocol version: 10
User: ****@localhost
MySQL charset: UTF-8 Unicode (utf8)
Web-Server
Apache/2.2.15 (Win32) PHP/5.2.13
MySQL client version: 5.0.51a
PHP extension: mysqli

Вероятно - тут дело в более строгих настройках MySQL-сервера,о чём впрочем давно и предупреждали.

Это врядли делает решение универсальным,т.к. оно требует определённых версий и настроек ПО - что, естественно, может предоставить далеко не каждый хостер.

[Виталий Желтяков]

Это врядли делает решение универсальным,т.к. оно требует определённых версий и настроек ПО - что, естественно, может предоставить далеко не каждый хостер.

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

Ну супер просто - уличная магия изменяет значения в записях???

И что дальше?
Пчёлы по законам аэродинамики летать не должны, а ведь летают...
Если хотите могу присобачить систему дублицирования категорий в БД, на вывод и поиск данных это никак не повлияет.
---
Но это не столь важно... Где ваши решения дабы сравнить их с моими?

[ssdm]

to Виталий Желтяков
Кстати , по поводу запросов ,как и обещал выкладываю SQL ные запросы. Рассмотрим три случая запросов для выборки статей по категориям(этот тип запросов будет самый) :
1) Запрос на выборку статей, где каждая принадлежит как минимум одной из перечисленных категорий.

select * from articles where id in (select  article_id from cat_at where cat_id in ( select id from categories where name in (<name_1>,...,<name_n>) ) ) ,

где name_i - название категории.
2) Запрос на выборку статей, где каждая принадлежит как минимум всем из перечисленных категорий в запросе.
3) Запрос на выборку статей, где каждая принадлежит только и не больше перечисленным категориям в запросе.

select * 
from articles 
where id in (
   select  article_id 
   from cat_at,categories
   where cat_id = categories.id
   group by article_id 
   having count(distinct case when categories.name in (<name_1>,...,<name_n>) then categories.name end)
                >= --для второго случая, для третего случая - строгое равенство
               :cat_count -- параметр - количество категорий, указанных в in списке
)

Сравните этот код запроса с вашем "оптимальным" запросом. Хорошо ещё что 5 категорий для одной статьи.

Добавлено :

1)ALter table сам по себе долго выполняется, а на вашей таблице(в которой хранится всё, и рубрики, и контент статьи ), ещё дольше будет + не забудьте про переиндексирование таблицы после изменения столбца с категориями. Вот вам и очевидный баг вашего подхода.
2) Если кол-во категорий на статью будет больше 5 ,надо переписывать почти весь код( практически все запросы к базе) + опять же Alter table(вместо обычного Insert в нормальном случае).

Если честно этих двух пунктов уже достаточно , что бы отказаться от вашего решения ,но давай те пойдем дальше.

3) Вы говорите что ваши запросы будут быстрее работать? А откуда у вас такая информация ? Вы проводили тесты? Скорее всего нет. Так что не говорите ерунды.

4) Неплохая статья где сравнивают ENUM и not EMUN

Поймите же вы, что ваша проблема не в том что вы выбрали поле Enum, а в том что вы неправильно спроектировали БД.

Добавлено 2:
И не надо сьезжать с темы, аля предоставте код и прочее. Я не подписывался вам сайт делать.
Вам указывают на явные проблемы в вашем подходе, а вы предлагаете "пис*ками мерится".

[Виталий Желтяков]

1)ALter table сам по себе долго выполняется, а на вашей таблице(в которой хранится всё, и рубрики, и контент статьи ), ещё дольше будет + не забудьте про переиндексирование таблицы после изменения столбца с категориями. Вот вам и очевидный баг вашего подхода.
2) Если кол-во категорий на статью будет больше 5 ,надо переписывать почти весь код( практически все запросы к базе) + опять же Alter table(вместо обычного Insert в нормальном случае).

Если честно этих двух пунктов уже достаточно , что бы отказаться от вашего решения ,но давай те пойдем дальше.

Во-первых, Я не претендую на высокую скорость редактирования категорий. Эта операция обычно доступна администраторам, и производится сравнительно редко. Мой код заточен под операции выборки, которые являются основными.
Во-вторых, достаточно просто написать функцию, добавляющую дополнительную 6-ю (и т.д.) категорию.

3) Вы говорите что ваши запросы будут быстрее работать? А откуда у вас такая информация ? Вы проводили тесты? Скорее всего нет. Так что не говорите ерунды.

Тесты Я проводил и убедился в правильности данного метода. Если представите своё решение то, мы свободно сможем провести публичные тесты.

Поймите же вы, что ваша проблема не в том что вы выбрали поле Enum, а в том что вы неправильно спроектировали БД.

Я уже писал - само использование ENUM есть нарушение теории БД, но оно быстрее.

[ssdm]

Тесты Я проводил и убедился в правильности данного метода. Если представите своё решение то, мы свободно сможем провести публичные тесты.

Я вам привел готовые SQL запросы. Вставьте их вместо аналогичных ваших и проверяйте. Ах да, у вас базы то нет ,тут и возникает вопрос , как вы тестировали ваш метод с нормальным методом, если базы не было ?
Если базы есть то тогда вперед ,делайте тесты.

о-первых, Я не претендую на высокую скорость редактирования категорий. Эта операция обычно доступна администраторам, и производится сравнительно редко. Мой код заточен под операции выборки, которые являются основными.
Во-вторых, достаточно просто написать функцию, добавляющую дополнительную 6-ю (и т.д.) категорию.

Согласен ,запросы на выборку будут проходить чаще, но зачем забывать про остальную функциональность(а задача изменения и дополнения категорий в ТЗ стояла).

Я уже писал - само использование ENUM есть нарушение теории БД

В общем случае не является

но оно быстрее.

Это смотря для каких целей сравнивать

Select * from table where field1=value1

На этом запросе быстрее, но на всех остальных нет (в пример ваш огромный запрос).

Добавлено: и кстати на сколько этот злочастный ENUM быстрее того же varchar ? Вот интересная статья с тестами http://www.mysqlperformanceblog.com/...hat-is-faster/

[Nikolai_]

Сообщение от Andkorol

PS : поле `id` AUTO_INCREMENT тут скорее всего не пригодится,потому что критичны либо сочетания article_id - category_id, либо только category_id - значит этих значений достаточно.
Не забудьте про индексы.

Andkorol, в смысле, что надо с индексами сделать?

[Andkorol]

Сообщение от Nikolai_

Andkorol, в смысле, что надо с индексами сделать?

Вам нужно проиндексировать оба поля.
Сделать это можно либо через phpMyAdmin, либо выполнив SQL-запросы:

ALTER TABLE `<table_name>` ADD INDEX ( `<field_name_1>` );
ALTER TABLE `<table_name>` ADD INDEX ( `<field_name_2>` );

Поиск по индексированным полям происходит гораздо быстрее.