MySQL Database Design, оптимизированный для извлечения данных в PHP

Question

Я довольно новый разработчик MySQL и начинаю проект, который я мог бы сделать с небольшим первоначальным советом по ...

Я создаю базу данных, которая в основном будет содержать определенное количество элементов (от 1 до 5 тысяч) и около 40 логических переменных, связанных с каждым. Затем пользователи будут вводить свой выбор из этих 40 значений, и задача системы состоит в том, чтобы определить «наилучшие» подходящие элементы. Это могут быть элементы, которые соответствуют всем 40 переменным, или, если их нет, те, которые соответствуют 39 и т. Д.

Итак, пара вопросов, если у кого есть время!

1. Из моего опыта работы с MySQL нет существенного преимущества в скорости разделения данных на отдельные таблицы для базы данных такого размера. Накладные расходы для большего количества таблиц просто слишком велики, чтобы иметь какое-либо реальное влияние на общую производительность. Поэтому я бы предложил просто создать одну большую таблицу с 40 столбцами и до 5000 строк для хранения всей информации (блокировка таблиц не является проблемой, так как все запросы будут SELECT). Совпадает ли это с мнением и опытом других?
2. Какой самый эффективный способ вернуть «лучший» матч? Возможно ли это даже возможно только через структуру базы данных и команды SQL, или мне придется просто вернуть весь массив в PHP и выполнить там эвристическую функцию, чтобы определить лучшие совпадения?

Спасибо за ваше время и помощь!

Answer 1

Один стол, безусловно, прав. Вы можете сохранить до 64 логических переменных в одном столбце BIGINT в виде «маски» с одним логическим значением на бит и очень быстро вычислить совпадение как BIT_COUNT(~(the_column ^ user_preferences)), которое подсчитает, сколько битов равно столбцу и маска, задающая пользовательские предпочтения (если в PHP возникают проблемы с манипулированием 64-битными целыми числами, вы можете использовать два столбца по 32 бита в каждом, сумма двух битов будет по-прежнему очень быстрой).

Answer 2

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

Здесь нет накладных расходов, так как MySQL предпочитает искать строки вместо столбцов. Функция count () пригодится тогда.

Я почти уверен, что если не удастся найти какое-либо совпадение, вам придется вернуться к PHP, чтобы запустить поиск, чтобы найти совпадение для 39 и так далее. Рекурсивная функция была бы хорошим способом сделать это.

, например

Таблица xOption идентификатор, имя

Таблица yOption идентификатор, имя

таблица xOption_yOption xOption_id, yOption_id

Еще одна хорошая вещь об этом - вы можете легко добавить больше опций X или Y позже в свою сетку, и вы также можете хранить больше деталей о Опциях.

не забудьте также использовать индексы.

Answer 3

Я бы использовал две таблицы. Один для элементов и один для логических флагов, которые соответствуют элементу. Вносить в таблицу «флаги» только совпадения для предмета. Затем, чтобы получить количество совпадений для элемента, будет просто количество записей в таблице 'flags', которые соответствуют itemId из таблицы 'items'.