Структура базы данных - это правильный выбор MySQL?

Question

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

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

Основываясь на различных справочных материалах и доступных источниках, мы составили списки плюсов и минусов всех основных и известных шаблонов баз данных, чтобы решить эту проблему. После сравнения мы пришли к двум последним вариантам:

• EAV (модель значения атрибута сущности):

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

  Минусы: все связанные запросы будут включать несколько объединений между несколькими таблицами для завершения сбора данных.

• SLOB (Сериализованный объект, также известный как Фасад?):

  Плюсы: очень гибкий. Сохранение количества необходимых объединений на низком уровне по сравнению с шаблоном проектирования EAV. Легко обновлять / добавлять / удалять данные из каждого продукта, но трудно сохранять целостность данных без дополнительных таблиц.

  Минусы: вся сортировка будет выполняться приложением, а не базой данных. Будет ли много производительности (памяти?), Когда большие наборы данных обрабатываются большим количеством пользователей.

Наши основные вопросы:

• Какой шаблон / структуру вы бы использовали, или, может быть, даже другое решение?
• Есть ли лучшие базы данных, кроме mySQL, доступные в настоящее время для достижения того, что мы хотим?

Большое спасибо!

Ссылка: Как составить таблицу продуктов для многих видов продуктов, где каждый продукт имеет много параметров

Answer 1

из вашего решения кажется, что вы не хотите использовать реляционную модель, поэтому, возможно, лучше не использовать реляционную базу данных, взгляните на эти альтернативы: http://nosql -database.org / Кстати, SQLServer имеет замечательные функции SLOB в виде полей xml (может быть проиндексирован с помощью XQuery)

Answer 2

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

Предполагая, как это часто бывает, что эти два параметра не обязательно должны быть синхронизированы абсолютно и мгновенно, вы можете легко получить гораздо лучшую общую производительность. Какие жесткие требования вы бы предъявляли к синхронизации? Миллисекунды до минуты?

Уди Дахан обладает хорошей информацией о разделении ответственности по командным запросам (CQRS), которое имеет отношение к делу. Смотрите также пару других статей . У InfoQ также есть очень соответствующее видео Грега Янга из QCon08.

РЕДАКТИРОВАТЬ: Вот еще одно видео (от Udi Dahan), которое обсуждает, среди прочего, преимущества нескольких моделей.

Answer 3

MySQL работает очень хорошо даже для очень больших наборов данных. Я использую его в компании SaaS, оказывающей финансовые услуги, и она всегда работала хорошо. Я также использую SQL Server и Oracle для очень больших приложений, и MySQL работает не лучше и не хуже в целом. Однако я сосредоточен на бизнес-уровне, и вы можете получить более подробные мнения от людей, которые находятся ближе к БД.

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

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

Кроме того, вы можете рассмотреть альтернативы SQL, которые пытаются создать шаблон, аналогичный тому, который вы наметили. Друг очень крупной, известной интернет-компании начинает использовать Project Voldemort . Он предпочитает это по сравнению с подобными усилиями главным образом из-за очень активного сообщества.