Ответы пользователя по тегу Проектирование баз данных
  • Идентифицирующая или неидентифицирующая связь?

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

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

    Но вообще это просто термины, нет смысла о них думать.
    Ответ написан
  • На какой стадии разработки веб-сайта моделируется база данных?

    @dimoff66
    Кратко о себе: Я есть
    Разработка без БД конечно возможна, но если БД будет готова до начала разработки - будет намного меньше траблов.
    Ответ написан
    Комментировать
  • Как хранить характеристики товаров в БД и делать поиск по ним?

    @dimoff66
    Кратко о себе: Я есть
    Характеристики относятся к товарам? То есть у одного товара только один набор характеристик или один товар может приходить и продаваться с разными наборами характеристик, например кроссовки адидас, цвет: Белый, размер: 37 и кроссовки адидас, цвет: Синий, размер: 39. Если второй, более сложный случай, то делаем следующие таблицы

    1) Таблица Properties (id, name, valueType) - здесь просто храним список возможных свойств
    2) Таблица PropertyValues (id, propertyId, value) - здесь храним возможные варианты значений для свойств, у которых не простой тип, то есть не строка, не число, не булево, не дата
    3) CharacteristicsSet (id, productId, name) - здесь будет храниться набор свойств для конкретной позиции товара на складе, name будет составляться автоматически как строка из свойств и их значений, указанных для позиции товара
    4) CharacteristicsValues (chartacteristicSetId, propertyId, valueType, value) - здесь будут храниться значения свойств для конкретной характеристики.

    Например нам пришли партии кроссовок со свойствами цвет: белый, размер: 37й и цвет: синий, размер: 39й. (например 100 и 50 штук соответственно)

    Тогда наши таблицы будут выглядеть следующим образом:

    Properties:
    id: 1, property: 'Цвет', valueType: 'set'
    id: 2, property: 'Размер', valueType: 'number'

    PropertyValues:
    id: 1, propertyId: 1, value: 'Белый'
    id: 2, propertyId: 1, value: 'Красный'
    id: 3, propertyId: 1, value: 'Синий'

    CharacteristicsSet:
    id: 1, productId: 777, name: 'Цвет: белый, размер: 37'
    id: 2, productId: 777, name: 'Цвет: синий, размер: 39'

    CharacteristicsValues
    chartacteristicSetId: 1, propertyId: 1, valueType: set, value: 1(ссылка на белый цвет)
    chartacteristicSetId: 1, propertyId: 2, valueType: number, value: 37
    chartacteristicSetId: 2, propertyId: 1, valueType: set, value: 2(ссылка на синий цвет)
    chartacteristicSetId: 2, propertyId: 2, valueType: number, value: 39

    Ну и в таблице склада можно будет хранить записи в виде:
    productId: 777, characteristicsSetId: 1, quantity: 100
    productId: 777, characteristicsSetId: 2, quantity: 50

    Если же различный набор свойств для одного товара нам не нужен, то все то же самое, но обходимся без таблицы CharacteristicsSet: а в CharacteristicsValues ссылаемся на сам товар. Соответственно весь поиск будет проходить по одной таблице CharacteristicsValues с индексированными полями. Например чтобы найти любые товары с цветом Белый, мы делаем поиск

    select * from CharacteristicsValues where propertyId = 1 and value = 1


    ну и с соответствующим соединениям по таблицам характеристик и(или) товаров
    Ответ написан
    Комментировать
  • Как спроектировать БД для доски объявлений?

    @dimoff66
    Кратко о себе: Я есть
    products
    - id
    - name
    - category_id
    categories:
    - id
    - name
    - parent_id (для внутренней иерархии)
    properties:
    - id
    - name
    - category_id (может быть указана ссылка на группу товаров)
    - value_type (ENUM: "string", "int", "boolean", "date", "list")
    list_values: (Заполняется для свойств с типом list)
    - id
    - property_id
    - name
    prop_values:
    - product_id
    - property_id
    - value (все пишем в строку, потом при получении преобразуем в нужный тип)
    Ответ написан
  • Как правильно хранить в Базе данных Разные названия одного фильма, тип фильма?

    @dimoff66
    Кратко о себе: Я есть
    movies: id, original_language, year
    movie_names: movie_id, language, name
    movie_statuses: movie_id, status(enum), updated

    Даже если статусы будут расширяться энум всегда можно расширить, проблемы нет, статусы хранить лучше в отдельной таблице с истоиией изменения
    Ответ написан
    1 комментарий
  • Как организовать схему складского учёта с перемещением в магазины под реализацию?

    @dimoff66
    Кратко о себе: Я есть
    Выход же совершенно очевидный - добавить в таблицу, где регистрируется наличие на складе поле price, и наверное поле date или ссылку на запись перемещения, из которой уже можно будет получить date. При списании списывать товары по FIFO, начиная с самой ранней даты.

    Тогда количество будет в разрезе цены на дату отгрузки.
    Ответ написан
    3 комментария
  • Структура базы данных магазина/каталога для SQL. Как лучше хранить атрибуты и их значения в БД?

    @dimoff66
    Кратко о себе: Я есть
    1) Не очень понятно назначение таблицы product_value, допустим у вас есть товар Куртка зимняя, у него есть два варианта (цвет: черный, размер: 42), (цвет: красный, размер: 43), и что будет в таблице?
    Четыре записи:
    Куртка зимняяЦвет черный
    Куртка зимняяЦвет красный
    Куртка зимняяразмер 42
    Куртка зимняяразмер 43


    И как вы определите, как эти свойства соотносятся и главное как вы это будете использовать?
    У вас же будут вноситься данные по продажам?

    Назначение этой таблицы в таком виде непонятно, я бы предложил сделать таблицы

    attributes_sets (модификации товара)
    • id
    • product_id
    • title


    и

    attributes_sets_values (значения свойств данной модификации)
    • attributes_set_id
    • value_id


    Тогда получится таблица вида

    Куртка: вариант 1 Цвет черный
    Куртка: вариант 1размер 42
    Куртка: вариант 2 Цвет красный
    Куртка: вариант 2размер 43


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

    Также можно писать в поле title таблицы attributes_sets значения модификации через запятую "черный, 42", это упростит вывод информации о модификации в отчетах.

    2) В product_value(или attributes_sets_values, если примените пункт 1) можно добавить поля attribute_id, value_int, это позволит для числовых атрибутов не задавать заранее список значений в values, а сразу указывать числовое значение

    3) Цены лучше не хранить в товаре, а сделать отдельные таблицы

    price_types: id, name
    prices: price_type_id, product_id, set_date, price

    Это позволит назначать товару разные цены в зависимости от всякого рода условий, можно также добавить в prices поле user_id, чтобы не возникал вопрос кто поменял цену
    Ответ написан
    1 комментарий