NoSQL - Дизайн базы данных: как правильно спроектировать или представить ассоциацию в схеме базы данных NoSQL? - PullRequest
Новая
       64

NoSQL - Дизайн базы данных: как правильно спроектировать или представить ассоциацию в схеме базы данных NoSQL?

0 голосов
/ 03 октября 2019

Я проектирую базу данных для приложения мойки автомобилей, над которым я работаю, и я хотел бы знать пару вещей. База данных будет либо в MongoDB, либо в Firebase / Firestore. Тем временем я потратил много времени на концептуализацию базы данных, и вот что я придумал:

enter image description here

Я хотел бы отметить это событие, хотяэтот дизайн включает в себя первичные ключи (PK) и внешние ключи (FK), они не будут представлены как таковые, когда я на самом деле создаю базу данных. Вместо этого они будут просто ссылками на внешние документы / таблицы. Итак, вот мои вопросы:

  1. Как вы думаете, ребята, база данных в ее простейшей форме была разработана правильно? Если нет Что я сделал не так?
  2. Как вы думаете, ребята, отношения между OrderDetails, Service, Addons и Order правильно построены?
  3. Должен ли Business быть подключен к Order вместо Service?

  4. При фактическом построении базы данных (MongoDB / Firebase / Any NoSQL), как я должен представлять OrderDetails? Как вложенный документ внутри Order или наоборот. Я немного запутался и это моя попытка;Пожалуйста, дай мне знать, что ты думаешь. 

    let order = {
    'order_id':'jxde5retvggfffgggv',
    'customer_id':'hdksjf456jvvhgkk',
    'date':'05-14-1985 13:00',
    'total_amount':'1500',
    'order_detail':[{
        'order_id':'jxde5retvggfffgggv',
        'service_id':'ope4fghgi9nnsgu',
        'addon_id': '4fhtyucfjfigpq9fh',
        'quantity': 20
    },
    {
        'order_id':'jxde5retvggfffgggv',
        'service_id':'7reaolmdgfirgt8om',
        'addon_id': 'sd2aqerthnnmgdpmb',
        'quantity': 35
    }]
}

[ОБНОВЛЕНИЕ - 5 ОКТЯБРЯ 2019] КОНСТРУКЦИЯ БАЗЫ ДАННЫХ

Я только что понял, что автомобиль, который нужно мыть, должен быть частьюпорядка, поэтому я немного изменил дизайн, чтобы отразить это. Тем самым я по-прежнему удостоверяю, что клиент по-прежнему доступен из заказа, поскольку к автомобилю прикреплено customer_id. Пожалуйста, дай мне знать, что ты думаешь.

enter image description here

1 Ответ

0 голосов
/ 04 октября 2019

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

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

  2. Поскольку служба содержит wash_type_id в качестве FK, вероятно, направление «один ко многим» на диаграмме должно бытьнаоборот. Я не совсем понимаю смысл этих отношений. Поскольку Сервис содержит описание и цену за единицу, я полагаю, что это предложение для клиентов. Но почему (вероятно) многие Сервисы указывают на один и тот же тип стирки? Возможно, имеет смысл разделить эти два, но, не зная ваших бизнес-требований, это трудно понять.

  3. Я не уверен насчет семантики бизнес-объекта. Относятся ли разные случаи к различным компаниям, предлагающим услуги автомойки? Если это так, ответ, вероятно, должен быть отрицательным, потому что разные компании вряд ли будут использовать одни и те же сервисные предложения. Однако если Business означает просто филиал одной и той же компании, то, возможно, сервисные предложения одинаковы для всех экземпляров Business, и Business может подключиться к Order. Зависит от ваших требований.

  4. Я не знаком с Mongo и Firebase, но я знаю Couchbase. Общее соображение проектирования для вложенных объектов заключается в том, что вы можете ссылаться на объект верхнего уровня только из других объектов, указывая его идентификатор. Таким образом, решение, которое вы предлагаете, приемлемо, если вы ссылаетесь только на заказы от других объектов, но не на конкретные OrderDetails. Это должно быть хорошо для многих случаев использования. Это, однако, затруднит оценку всех OrderDetails, которые использовали конкретную Услугу, - найдя эти средства, чтобы открыть все Заказы, чтобы выяснить, относятся ли некоторые их детали к этой Службе. Обратный путь вообще не имеет смысла. OrderDetail содержится в Order, а не наоборот. Создание корня OrderDetail и включение в него Order означало бы избыточное повторение данных заказа для каждого экземпляра OrderDetail. Однако, если вы хотите сделать OrderDetail объектом первого класса, вы можете полностью отделить его от Order.

...