Задать вопрос

alexalexes

Ответы пользователя по тегу Проектирование баз данных

  • Как найти общие поля в таблицах?

    @alexalexes
    Если задача на знание справочника SQL, то есть такая конструкция:
    таблица1 join таблица2 using (общие_имена_полей)
    это эквивалент:
    таблица1 join таблица2 on таблица1.общее_имя_поле = таблица2.общее_имя_поле...

    Вариант с using будет работать, если выдерживается культура именования, при которой в названии поля есть название таблицы.
    Ответ написан
    3 комментария
    3 комментария

  • Есть ли нарушение 3NF и BCNF в таблице БД?

    @alexalexes
    Если задача автоматизированной системы строить график уровня запаса (выполнять функцию подсистемы аналитики), то такая схема полностью уместна.
    PS:
    Но в реальной жизни у вас на месте таблички "Запас товара" будет "История завоза и вывоза товара", по которой у вас не будет явной цифры остатка товара, вам придется всегда его считать по sum() за период времени.
    Ответ написан
    1 комментарий
    1 комментарий

  • Как хранить онлайн статус пользователя?

    @alexalexes
    сделать 1 строка -> 1 пользователь и при запросе к апи делать update времени?

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

  • Какая логика поднятия объявлений в топ?

    @alexalexes
    Я бы построил бы структуру таблиц так, чтобы можно было бы выполнить такой запрос (по версии sql Oracle):
    -- премиум выборка
select  1 as priv_type, -- тип привилегии 1 - премиум объявление
    C.*
from
(
  select B.*,
             dense_runk() over (order by B.user_id) as user_num, -- нумеруем авторов объявлений
             row_number() over (partition by B.user_id order by rownum) as add_num -- нумеруем объявление в пределах автора
  from
  ( -- достаем премиум объявления в случайной сортировке
     select A.*
       from A
     where premium_pay_date is not null and sysdate - premium_pay_date <= 3 -- условие попадания в премиум
  order by DBMS_RANDOM.RANDOM
   ) B
) C
where user_num <= 5 -- берем 5 авторов
   and add_num = 1  -- по одному объявлению от автора
union
-- обычная выборка
select 2 as priv_type, -- тип привилегии 2 - обычное объявление
         A.*,
        -- зануляем доп. поля от премиум, чтобы union работал корректно
        null user_num,
        null add_num 
  from A
  where premium_pay_date is null or sysdate - premium_pay_date > 3 -- можно исключить премиум из общей выборки, а можно не исключать
order by priv_type, Publication_Date desc
    Ответ написан
    Комментировать
    Комментировать

  • Делаю to do веб-приложение. Как реализовать логику повторения задач?

    @alexalexes
    В вашей структуре данных будет как минимум 3 схемы хранения данных, отвечающие за разные подсистемы:
    1. Схема для подсистемы управления учетными данными пользователей
    Подсистема отвечает за регистрацию пользователей, аутентификацию. То есть, позволяет пользователю при предъявлении своего токена (логина и пароля), как-то соотнести его с учеткой в системе. Или помочь восстановить доступ к этой учетке.
    2. Схема для подсистемы прав доступа
    Перечисленная структура таблиц позволяет создать шаблон роли пользователя с заранее оговоренными допустимыми действиями над определенными типами задач. И применить шаблон роли на пользователе - создав роль пользователя.
    Данные из этой подсистемы позволяют проводить авторизацию пользователя, ограничивая его область привилегий.
    Для этой подсистемы нужно уточнять требования, чтобы понять насколько вам нужен шаблон ролей, какие свойства в него должны входить и т.д. От этого будет зависеть структура таблиц.
    3. Схема для подсистемы планировщика задач
    В этой подсистеме можно создать шаблон задачи, назначить номинальных куратора и исполнителя (пока что по одному пользователю, если нужно больше, то расширяйте это таблицами со связями многим-ко-многим).
    Есть возможность назначать задачу на конкретный календарный период (и не один раз) - с указанием фактических куратора и исполнителя (тоже по одной единице - надо больше расширяйте структуру таблиц). Наличие таблицы календарного планировщика позволяет зафиксировать параметры выполнения задачи во времени, если в ней будут непредвиденные изменения в кураторах и исполнителях, перенос на другое время.
    Нужно определиться как генерировать задачу для таблицы-календаря - заранее накидать фактические даты выполнения на неделю, месяц, год, и потом их корректировать по обстоятельствам, или назначать следующую дату выполнения после истечения периода выполнения предыдущей.
    Схема таблиц позволяет любой из этих вариантов.
    Также из задач можно построить дерево задач и нанести каждую подзадачу в планировщик (есть связь таблицы по родителю).

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

    ----------------------------------------
    Схема таблиц учетных данных пользователей

    Пользователь
    #* Код человека
    *Дата регистрации
    * ФИО
    *Адрес электронной почты
    * Хеш пароля

    -----------------------
    Схема таблиц прав доступа пользователей

    Шаблон роли пользователя (модель роли)
    #* Код шаблона
    * Название роли

    Действия прав доступа (справочник)
    1. Код действия
    2. Название действия (просмотр, назначение, отмены, удаления, переноса задачи, редактирования шаблонов задач, редактирования планировщика задач)

    Cвойства шаблона прав доступа
    1. Код свойства прав доступа
    2. Код шаблона роли
    3. Код действия прав доступа
    5. Код типа задач
    4. Дата создания свойства

    Роль пользователя (реализация роли пользователя)
    1. Код прав доступа пользователя
    2. Код шаблона роли
    3. Код пользователя

    ------------------
    Схема таблиц планировщика задач пользователей

    Тип задачи
    1. Код типа задачи
    2. Название типа задачи

    Шаблон задачи (модель задачи)
    1. Код шаблона задачи
    2. Код типа задачи
    3. Код родителя шаблона задачи (на сущность Шаблон задачи)
    4. Наименование задачи
    5. Описание задачи
    6. Дата создания шаблона
    7. Периодичность выполнения
    8. Код пользователя (номинальный куратор)
    9. Код пользователя (номинальный исполнитель)
    10. Дата назначения номинального куратора
    11. Дата назначения номинального исполнителя

    Календарь задач (реализация задач, он же планировщик)
    1. Код элемента
    2. Код шаблона задачи
    3. Дата начала выполнения задачи
    4. Дата окончания выполнения задачи
    5. Код пользователя (фактический куратор)
    6. Код пользователя (фактический исполнитель)
    7. Дата назначения фактического куратора
    8. Дата назначения фактического исполнителя
    ---------------------

    PS: Можете из этого перечня таблиц и их атрибутов нарисовать DFD диаграмму или диаграмму по Ричарду Баркеру. Правда, тут не обозначены явно связи, но можно догадаться по названию внешних ключей, как связаны таблицы.
    Ответ написан
    1 комментарий
    1 комментарий

  • Как лучше хранить мелкие данные в базе?

    @alexalexes
    В самом кратком варианте у вас будет одна таблица, которая будет отвечать за дерево страниц.
    Таблица pages:
    id - идентификатор страницы;
    parent_id - идентификатор родителя страницы;
    title - Название страницы
    short_name - Краткое наименование (обычно используются для пунктов меню)
    alias - имя алиаса для построения url страницы (то что вы указали как type: about, advantages, etc...)
    create_date - дата-время создания страницы
    update_date - дата-время изменения страницы
    content - тело страницы
    is_hidden - флаг скрытости страницы (удобно использовать для устаревания страниц)
    PS: Посмотрите как это реализовано в любой популярной CMS, похожая таблица и свойства таблиц есть в любой из реализаций.
    Ответ написан
    Комментировать
    Комментировать

  • Как хранить закупочную цену в интернет-магазине?

    @alexalexes
    Элементарно. Если какой-то атрибут может менять значение со временем, то он обретает вид табличных данных.
    Таблица "Цена":
    id_cost - идентификатор цены;
    id_cost_next - следующая цена;
    id_good - идентификатор товара (внешний ключ таблицы "Товары");
    id_delivery - идентификатор поставки (внешний ключ таблицы "Поставки");
    id_type - тип цены: розничная/закупочная (внешний ключ таблицы "Типы цен");
    date_set - дата/время установки цены;
    id_currency - идентификатор валюты: р. руб/евро/доллар (внешний ключ таблицы "Валюта").
    value - значение цены.

    При добавлении нового значения цены необходимо предыдущей записи цены по текущему товару устанавливать id_cost_next равный текущему значению id_cost.
    Текущая цена на товар будет определяться id_cost_next is null, ретроспективные - id_cost_next is not null.
    Самая ранняя установленная цена по товару будет определяться по min(id_cost) в пределах текущего товара.
    Ответ написан
    2 комментария
    2 комментария

  • Система Библитека. Как спроектировать БД для хранения многих экземпляров книг и функционала по заказу этих книг?

    @alexalexes
    В дополнение к сущности "книга":
    Books (id, title, description, year, cover, idAuthor, idGenre)
    Добавить таблицу "экземпляр книги":
    BookEntities (id, -- идент. экземпляра книги
    idBook, -- идентиф. книги
    add_date, -- дата внесения в каталог
    exc_date, -- дата исключения из каталога
    deterioration, -- изношенность
    wieght -- вес
    )
    А в таблицах выдачи/приема уже оперировать экземплярами книг.
    PS: Не всегда в библиотекарской системе требуется такая детализация, может оказаться так, что достаточно отслеживать баланс между макс. кол-во книг, и сколько выдано, при помощи триггеров в базе.
    Ответ написан
    5 комментариев
    5 комментариев

  • Организация базы данных mysql?

    @alexalexes
    Смотрите, как реализовывается связь "многие ко многим".
    То есть, вам нужна промежуточная третья таблица.
    partner_and_product_type
    part_id - идент. партнера
    prod_type_id - идент. типа продукции.
    Тогда сможете вносить на любого партнера несколько типов продукции.
    Ответ написан
    2 комментария
    2 комментария

  • В каком виде хранить данные о товарах в бд?

    @alexalexes
    В таблице param задавайте тип данных этого параметра, а таблице product_param весь набор полей данных, который нужен будет для описания любого параметра. Могут быть не только типы, стандартные для БД, но и по предметной области (интервалы, габариты и тд).
    param (id, type_data /*тип данных параметра или размерность (лучше размерность вынести еще одним свойством)*/, name)
    product_param (product_id, param_id,
    value_int -- целое
    value_int2 -- целое для типов интервалов целых (с value_int по value_int2 )
    value_str -- строка
    value_date -- дата
    value_date2 -- дата для типов интервалов дат (с value_date по value_date2)
    )
    Ответ написан
    Комментировать
    Комментировать

  • Какая лучшая практика наименования полей таблицы в MySQL?

    @alexalexes
    Тут дело выбора стандартов внутри группы разработчиков, как договоритесь использовать имена.
    Например, второй способ избыточен при таком подходе написания запросов.
    select country.country_id
from country

    а вот здесь чуть полегче разобраться к чему относиться псевдоним таблицы:
    select c.country_id
from country c

    Если умело сокращать имена псевдонимов, то жить можно и при кратком подходе именования:
    select ctry.id
from country ctry

    Если загвоздка иного рода - именовать поле country_id или id_country.
    Первый вариант правильный с точки зрения англ. языка, а второй - визуально легче отслеживать виды полей, если их записать вертикально.
    Ответ написан
    Комментировать
    Комментировать