Вот решил с целью сео сделать для каждого файла уникальный адрес без всяких id и прочего лишнего мусора. Типа такого /Igorq_Rasteryaev_Koncert_v_Kurske_2_11_2013.xhtml
Сложность состоит в том что этих файлов будет реально десятки а то и сотни миллионов а вообще я хз но зняю точно что дохера.
Хотелось вынести эти индексы в отдельную таблицу типа |URL_KEY|TABLE_NAME|FILE_ID| но минус в том что для получения данных нужно делать два запроса с базы данных, первый для получения id второй для получения информации по полученному id.
Решение пришло в голову сделать универсальную таблицу для разных типов |URL_KEY(Primary key)|TYPE(вместо TABLE_NAME)|FILE_ID|FILE_NAME|PRIVATE_VARIABLE(serialize(array))|И еще пару общих параметров|
Такая архитектура базы мне больше нравится, и для самой архитектуры движка сайта. Но половина запросов в базу будет идти не по URL_KEY а по TYPE AND FILE_ID
У меня всегда были проблемы с структурированием таблиц. Вопрос в том как тут будет проще структурировать таблицы, сделать кучу таблиц или все же вложить все в одну?

я не совсем понял проблему. если url будут уникальными, то просто уникальный индекс ставь и все.

Сегодня вообще решил захерячить кирилические юрлы. В этом много прлюсов. Даже при потере базы данных я с легкостью найду нужный файл. Или например при удалении файла легко будет найти похожие

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

джоин повлияет, кончно. но хорошая архитектура важнее производительности.

Gemorroj написал:

хорошая архитектура важнее производительности

Знаешь наверное ты прав