Как создать следующую модель базы данных?

Question

Я создаю систему с несколькими сущностями, эти объекты имеют некоторые общие свойства, такие как имя, номер телефона и адрес и т. Д. С другой стороны, эти объекты имеют некоторые необычные свойства.

Чтобы сделать его более понятным, объекты: рестораны, больницы, клиники, аптеки, медицинские лаборатории, ремесленники, система предназначена для ранжирования этих рангов и обзоров, введенных пользователями.

Другими словами, мне нужно реализовать еще одну систему yelp.com.

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

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

Answer 1

• Если вы решили использовать СУБД, как SQL-сервер или MySQL, и все еще хотят де-нормированной структуру, вы можете попробовать Entity-Attribute-Value Model. Существует также этот вопрос перечисляя плюсы и минусы этого типа модели:

  Entity Attribute Value Database vs. strict Relational Model Ecommerce

---

• Если вы еще не фиксированы с реляционными базами данных, я хотел бы предложить вам прочитать около NoSQL базы данных, такие как MongoDB и CouchDB.

Answer 2

Это были раздуты, но CQRS может defenitly помочь вам здесь. Просто читать и исследовать об этом сделает вас лучше подготовлены, если вы не идете с чистым CQRS (независимо от того, что есть)

Ключ для оптимизации поиска является

• нет присоединения

  реляционная база данных знают, что присоединяется, конечно, но вы можете свести к минимуму их «денормализация» для ускорения запросов

• имеют лучшие индексы возможно

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

Если вы действительно нужно масштабировать (в отличие от масштабов), то есть вы хотите, чтобы получить производительность, просто добавив машины, вы должны прочитать около базы данных noSQL, так как они позволяют ошпаривать и все о не присоединяются. Я не знаю достаточно о них, как они ведут себя с поисками, кроме поиска (что очень быстро из-за осколков). У них есть недостатки, как отсутствие хорошей поддержки отчетности ad hoq, хотя вам нужно исследовать/экспериментировать/доказывать концепцию.

Answer 3

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

В дизайне базы данных много обсуждений наследования, а некоторые - discussed here.

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

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

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

Оптимизация для поиска будет зависеть от того, как определяются ваши поисковые запросы. Например, если вы ищете по местоположению, у вас могут быть теги, отмеченные только областью метро или полной географической привязкой. Существует индексация, которая поможет вам найти на расстоянии от места. Если вам нужно выбрать только определенные типы объектов, вы должны убедиться, что ваши индексы включали этот столбец. На данный момент денормализация не поможет вашему поиску так же, как индексирование, которое охватывает запросы. Денормализация работает лучше всего, когда результирующие множества велики. Точкой поиска является предоставление пользователям наборов результатов, которые по определению должны быть небольшими, чтобы они могли найти их полезными. Список 1000 ресторанов не полезен для пользователя, так как они могут есть только за несколько минут в день.

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