Представим что есть информационный сайт со 100к статьями и 500к комментариями (строю с запасом). Скажите, будет ли реальная экономия, если вместо прочёсывания таблицы с комментами по id статьи ______ сделать при добавлении нового коммента дописывание в статью через разделитель?
Т.е. в таблице articles сделать столбец comments_id и в него писать id;id;id;id, а при выводе комментов просто разбирать id'шники и выводить? Повторюсь, комментов 500к (в примере).
Полная Версия: Много статей и комменты
Нет, не лучше... А потом как ты будешь получать, к примеру все комменты к статье? Будешь id'шники на массив разбивать? Сколько памяти на это может понадобиться, не думал?
Выборка по primory key будет быстрее, чем по любому другому ключу - факт. Только вот это решение не расширяемо и те, кто будут после вас работать с этим кодом, "спасибо" точно не скажут, а скорее заставят икать до самого смертного одра.
Т.е. проход 500к записей меньше ест чем разбор массива из 10(+10) элементов с последующим выводом? И еще вопрос, в каком случае меньше времени на генерацию уйдет? Сейчас VPS'ка с 2 ГБ памяти.
| Цитата (Nikitian @ 23.06.2013 - 20:53) |
| Выборка по primory key будет быстрее, чем по любому другому ключу - факт. Только вот это решение не расширяемо и те, кто будут после вас работать с этим кодом, "спасибо" точно не скажут, а скорее заставят икать до самого смертного одра. |
А в чем проблема? В таблице комментов будет дублироваться id статьи.
Так не будет никакого прохода по 500к записей. Будет выборка по индексу. Индекс у вас будет занимать пару мегабайт в памяти.
Время на генерацию зависит от множества факторов и тут даже приблизительно нельзя ничего сказать. надо смотреть конкретную реализацию.
Время на генерацию зависит от множества факторов и тут даже приблизительно нельзя ничего сказать. надо смотреть конкретную реализацию.
| Цитата (asdf27 @ 23.06.2013 - 20:56) |
| Т.е. проход 500к записей меньше ест чем разбор массива из 10(+10) элементов с последующим выводом? И еще вопрос, в каком случае меньше времени на генерацию уйдет? Сейчас VPS'ка с 2 ГБ памяти. |
База MySQL
| Цитата (Nikitian @ 23.06.2013 - 20:58) |
| Так не будет никакого прохода по 500к записей. Будет выборка по индексу. Индекс у вас будет занимать пару мегабайт в памяти. Время на генерацию зависит от множества факторов и тут даже приблизительно нельзя ничего сказать. надо смотреть конкретную реализацию. |
Я имею ввиду запрос вида
SELECT * FROM comments WHERE article='$article'
Не совсем понимаю, пошел читать про индексы.
asdf27, не забывайте что 500к коментов за один раз никто дергать не будет, в здравом уме и трезвой памяти, а уж тем более "выплевывать" все это в браузер. Для таких вещей используется постраничная навигация и тут-то ваше "ноу-хау" сделает вам "секир-башка" с предварительным "выносом мозга"...
_____________
Стимулятор ~yoomoney - 41001303250491
_____________
Стимулятор ~yoomoney - 41001303250491
| Цитата (Valick @ 24.06.2013 - 03:11) |
| asdf27, не забывайте что 500к коментов за один раз никто дергать не будет, в здравом уме и трезвой памяти, а уж тем более "выплевывать" все это в браузер. Для таких вещей используется постраничная навигация и тут-то ваше "ноу-хау" сделает вам "секир-башка" с предварительным "выносом мозга"... |
Вы о чем? Вы куда?
500к комментов - суммарное количество. На каждую статью не более 20 комментов приходится.
ЕЩЕ ВОПРОС
В таблице статей будет поле cats, содержащее массив id'шников категорий через разделитель. При выводе категории, эти поля будут разбираться (требуется возможность указать несколько категорий при сохранении).
Скажите, если для этого поля я сделаю обычный индекс, а для id в таблице категорий уникальный, это будет быстрее, нежели без обычного индекса в поле cats?
Правильно ли я понимаю, что при запуске mysql-сервера сразу происходит индексирование?
Еще кое-что забыл. Не будет ли лучше ввести промежуточную таблицу id_статьи|id_рубрики ? При сохранении нужно блокировать таблицу?
Здесь расположена полная версия этой страницы.