Хорошее решение для хэширования PHP / MYSQL для большого количества текстовых значений

Question

Краткое описание:

Требуется решение алгоритма хеширования в php для большого количества текстовых значений.

Длинное описание.

PRODUCT_OWNER_TABLE
serial_number (auto_inc), product_name, owner_id

OWNER_TABLE
owner_id (auto_inc), owener_name

Мне нужно вести базу данных из 200000 уникальных продуктов и их владельцев (И все последующие изменения в собственности). У каждого продукта есть один владелец, но у владельца может быть МНОГО разных продуктов. Имена владельцев - «Адам Смит», «Джон Ривз» и т. Д., Только текстовые значения (вполне вероятно, также и в Юникоде).

Я хочу оптимизировать структуру базы данных, поэтому я думал, что каждую неделю, когда я запускаю этот скрипт, он выбирает владельца гордости, а затем проверяет таблицу, которая, как мне кажется, похожа на PRODUCT_OWNER_TABLE, выбирает owner_id. Затем он ищет owner_id в OWNER_TABLE. Если это совпадает, то это то же самое, поэтому он движется дальше. Проблема в том, когда все по-другому ...

Чтобы оптимизировать базу данных, я думаю, что я должен проверить другие записи "owner_name" в OWNER_TABLE, чтобы увидеть, существует ли там это значение. Если это так, то я должен использовать этот owner_id. Если это не так, то я должен добавить еще одну запись.

Обратите внимание, что в названии нет ничего особенного. до тех пор, пока я поддерживаю правильные ссылки и создаю таблицу типов OWNER_TABLE "только для чтения, добавление-добавление", я могу создавать исторический архив владения.

Мне нужно выполнить эту проверку для 200000 записей, при этом я не знаю, сколько уникальных имен владельцев (~ 50000?). Я думаю, что мне нужно решение для хеширования - OWNER_TABLE не будет отсортирован, поэтому алгоритмы поиска не будут оптимальными.

язык программирования - PHP. база данных MYSQL.

Answer 1

+ 1 200000 записей не так велики, MySQL может обрабатывать гораздо больше. ИМХО, единственная конструкция, которая здесь есть, является самой простой и наиболее эффективной: отношение один ко многим с индексами по ключу (как первичными в таблице владельцев, так и внешними в таблице продуктов).

Если ваша оптимизация направлена ​​на то, чтобы получить результаты быстрее или уменьшить нагрузку на сервер, и если ваши записи изменились или были удалены / повторно вставлены, вы можете попробовать OPTIMIZE

OPTIMIZE TABLE `Owner`;
OPTIMIZE TABLE `Product`;

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

(Предоставляются ссылки для mysql 5.0, настройте для получения документации по вашей версии)

Answer 2

То, что вы предлагаете, является сложным, сложным в обслуживании, избыточным и не улучшит ни функциональность, ни производительность.

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

Проблема несколько усложняется использованием суррогатных ключей (значения с автоматическим приращением). Исходя из вашего описания, реальный уникальный идентификатор владельца - это owner_name - в этом случае, и поскольку MySQL не поддерживает ограничения как таковые, он должен создать уникальный индекс для owner.owner_name - и всегда пытаться вставить туда значение всякий раз, когда вы добавьте продукт или измените владельца продукта - вы можете указать, что запрос игнорирует дубликаты, - тогда, если в качестве возвращаемого этим запросом значения__блокировки указано значение 1, извлеките идентификатор вставки, в противном случае опросите уже сохраненный ключ.

C.