Как бы вы нормализировали/оптимизировали эту базу данных mysql?

Question

У меня есть сайт для объявлений, в котором много категорий.

Когда пользователь публикует «объявление» на веб-сайте, есть некоторые основные сведения (имя, город, цена, заголовок, текст и т. Д.), Которые необходимо заполнить. А также, в зависимости от того, категория 'пользователь вводит объявление для вставки объявления, необходимо заполнить еще несколько полей, например: если категория - это «автомобили», тогда также появляется пробег «год».

Теперь мой поисковик запрос таблицы для любой пользователь выбирает для поиска ...

Мой вопрос, как бы вы кладете эту базу данных, чтобы быть наиболее эффективным и быстрым?

Я прочитал о нормализации, но на самом деле не понимаю многое из этого ... Итак, что бы вы ни объяснили, пожалуйста, объясните это как можно более основательное.

Благодаря

Answer 1

Я хотел бы начать здесь, чтобы узнать о нормализации:

http://en.wikipedia.org/wiki/Database_normalization

или здесь

http://databases.about.com/od/specificproducts/a/normalization.htm

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

http://www.phlonx.com/resources/nf3/

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

Answer 2

Хорошая книга для начала обучения это Database Design for Mere Mortals Майкл Джеймс Эрнандес.

Answer 3

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

Если скорость является целью, вам действительно нужно будет de -normalize вещи. Сложные объединения обычно являются узкими местами производительности в больших базах данных, а сокращение количества объединений путем денормализации таблиц повышает производительность.

Answer 4

Есть много способов, чтобы идти об этом, вот некоторые из них:

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

2. Отдельная таблица с общей информацией, а затем столбец для метаданных, хранящихся в виде xml, json или другого сериализованного формата. Используя эту технику, вам, вероятно, нужно будет использовать что-то вроде Lucene для индексации ваших метаданных для поиска.

Answer 5

Ниже приведены мои баллы 1) Правильно используйте индексы, чтобы ускорить выбор запросов.2) Совокупные навигаторы/редиректоры запросов: это технология, которая автоматически направляет запрос на агрегированные данные, если такие данные доступны и подходят для запроса. 3) Разделение: разбиение на разделы происходит во многих формах и формах. По крайней мере, это разделение одной таблицы на несколько таблиц, обычно основанных на времени представления данных таблицы. 4) Параллельное выполнение запроса - Sachin Chourasiya

Answer 6

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

Рекламный стол - интересная деталь: у вас есть выбор из двух с половиной.

• 1) один стол, чтобы держать их всех: одну таблицу, которая имеет все поля, необходимые для всех категорий
  • Pro: легко настроить
  • Pro: просты в обслуживании (только одна таблица для резервного копирования, для изменения и т. д.)
  • pro: очень простой SQL, который упрощает разработку интерфейса
  • жулик: не очень хорошо масштабируется
  • жулик: отходов некоторого пространства, которое будет замедлять базу данных в долгосрочной перспективе (в зависимости от структуры базы данных и таблиц, хотя)
• 2) одна таблица в категории
  • про: весы лучше, чем (1)
  • жулик: очень сложный SQL
  • жулик: кошмар для поддержания: вместо одной таблицы вы должны изменить, возможно, 100s

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

Я должен вам половину варианта: если вы не связаны с mysql, postgresql может предложить интересную альтернативу: наследование таблицы. в pg вы можете определить таблицу ads, которая содержит вашу базовую структуру и производную таблицу cars, которая содержит все поля ads, а также дополнительные (определенные для автомобиля) дополнительные поля. И стол для электроники, и один для фотографического оборудования и т. Д., Вы называете это. Вы даже можете пойти дальше и создать таблицы vans и convertibles, которые не наследуют от ads, а от cars, создавая дерево категорий, которое представляет иерархию объектов вашего интерфейса. Так в чем разница до (2) вы могли бы спросить?Упрощение обслуживания упрощается, изменение структуры таблицы ads распространяется на все производные таблицы (в то время как изменение в таблице cars будет только изменять cars, convertibles and vans, как и следовало ожидать). То же самое касается sql: если вы select * from ads where title='foo', запрос будет возвращать записи из ads и всех производных таблиц, всего дерева, если вы выберете из cars только поиск поддерева .. вы получаете идею. Есть еще кое-что, ваша поисковая система могла бы вытащить структуру/метаданные ваших таблиц категории и создать для нее интерфейсы поиска, поэтому ваш интерфейс поиска всегда синхронизирован с структурой данных и т. Д.

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

---

Последнее слово о mysql и postgres. pg - это база данных, в которой IMHO в большинстве аспектов сегодня превосходит mysql, просто не так знаменит. И нет, я не просто поклонник postgres, я старший пользователь mysql, я начал использовать mysql с версией 2.something, я представил ее более 10 лет назад в компании, в которой я все еще работаю (и сделал это база данных по умолчанию), и сегодня я не допускаю никакой новой разработки, я могу решить, основываться на mysql. Причина проста: по умолчанию «механизм хранения» в mysql - это myisam, который является быстрым и тощим и предлагает множество функций .. и вы потеряете данные в долгосрочной перспективе, если вы его используете. IMHO вы можете использовать его только для волатильных данных, и есть лучшие альтернативы для запуска кеша. если вам приходится полагаться на ваши данные, myisam - это NOGO. Я тестировал Innodb, по умолчанию для транзакционного механизма хранения, несколько раз за эти годы, и я никогда не нашел удовлетворительной производительности, поэтому я пошел на альтернативы.

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

нормально, достаточно адвокации на сегодняшний день, я пойду в постель :-)

Answer 7

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

объявления

• ID
• имя
• город
• цена
• заголовок

автомобили

• ID
• ad_id
• пробег
• год

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

Другим вариантом, который должен возникнуть, является сохранение полей и их значений в виде пар ключ-значение в таблице свойств. Я настоятельно рекомендую не использовать этот маршрут «build-database-inside-database». Рано или поздно вы столкнетесь с проблемами. Основная причина боли в том, что вам придется придать всем вашим значениям тот же тип данных, который часто оказывается VARCHAR. Это означает, что фильтрация и сортировка нетекстовых значений (например, числовые, дата/время и т. Д.) Станут чрезвычайно громоздкими.

Answer 8

MongoDB был разработан для ситуаций, подобных этому.