2014-01-25 2 views
0

Хорошо, я пытался понять это, но не смог прийти к выводу. Я хотел бы получить некоторые результаты от y'all, советы по проведению еще нескольких тестов или другие ресурсы для чтения.MySQL Оптимизация для 1-to-* отношений

Ситуация проста. Существует основная таблица изображений. Возможно, из cat_pictures. Существует вторичная таблица cat_pictures_comments. Некоторые умные разработчики убедились, что cat_pictures имеет первичный ключ с автоматическим приращением ID_PICTURE, а комментарии хранятся с индексом ID_PICTURE.

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

ли мы

  1. Просто INNER JOINcat_pictures с cat_pictures_comments (и убедиться, что все правильно упорядочены)

  2. Получить все cat_pictures, затем петлю через каждый и получить cat_pictures_comments для каждой картины

A: Что, если приложение является PHP?

B: Что, если cat_pictures имел идентификатор записи, путь к файлу изображения и еще 20 285 полей для генома кошки? И cat_pictures были также INNER JOIN 'ed с каждым психиатром владельца кошки (соотношение 1-1). (В принципе, есть больше данных, прикрепленных к первичной таблице, по сравнению с нашей небольшой таблицей комментариев.)

Спасибо всем.

+0

Вопрос неясен. Ответ - это соединение. Подумайте о том, чтобы предоставить таблицу приложений для данных 1-1, но только если можно продемонстрировать, что есть существенное преимущество в производительности. Если есть сомнения, проверьте. – Strawberry

+0

Извините.Это то, что я говорю, я не уверен, как измерить преимущества использования PHP, чтобы получать комментарии по каждому снимку или использовать запрос для его получения. У меня создается впечатление, что PHP * может быть лучше, поскольку память для хранения и возврата дублированных данных 'cat_pictures' может значительно перевесить небольшой размер каждого комментария, прикрепленного к изображению. – Liandri

+0

Хотя на практике это предположение невероятно маловероятно. Как правило, чем меньше «круглых поездок» в БД, тем лучше - с «1» является оптимальным. – Strawberry

ответ

1

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

Вариант 1

select (all pic columns), (all comment columns) from pics inner join comments; 

Vs. Вариант 2

Select * from pics; then loop and select * from comments were pictureId = @currentId; 

Vs. Вариант 3

Select * from pics order by picId; select * from comments order by picId; 

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

В варианте 2 вы сделали бы слишком много круговых поездок в базу данных, если бы было много фотографий.

Основываясь на отсутствии полных требований, я бы рекомендовал вариант 3. Получите результаты таблицы и комментарии в виде двух отдельных наборов данных, а затем на вашей php-странице: просмотрите каждый pic и отобразите pic-информацию, затем вложенный цикл в получить комментарии к текущему изображению из локального набора данных комментариев, которые уже были извлечены из SQL Server.

+0

Я не вижу логики одобрения 3 в течение 1. Я думаю, вы бы изо всех сил пытались разработать сценарий, в котором 3 из них были 1, но были бы счастливы оказаться ошибочными. – Strawberry

+0

@Strawberry, мне кажется, что 3 * может * превосходить 1, если данные, возвращаемые в «первичной» таблице, чрезмерны ... если количество данных в нем создает достаточно большие издержки данных. Нет? Поскольку для каждого комментария эти данные дублируются на выходе – Liandri

+0

Другие РСУБД могут быть лучше. Тем не менее, MySQL любит (правильно проиндексированные) данные. И это очень хорошо при обработке. Он будет бить руки PHP. – Strawberry

Смежные вопросы