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

Я довольно плохо знаком с работой с базами данных, думаю, я понимаю, как моделировать данные для графической базы данных, такой как neo4j, но у меня возникли трудности, когда дело дошло до работы со временем. Я попытался узнать о базах данных СУБД, таких как MySQL, ниже я думаю, что данные должны моделироваться. Пожалуйста, укажите, если я иду в неправильном направлении, или если другой тип базы данных будет более подходящим, это будет с благодарностью!

Основные данные
Вот некоторые основные данные для работы, прежде чем мы учтем планирование / время.

Работник
- Идентификационный номер
- Имя
- Навыки (Блэкджек, Баккара, Рулетка и т. Д.)

Таблица
- Идентификационный номер
- Навык / Тип (может быть только один навык)

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

Возможные Запросы
Примечание. Персонал, работающий в смену, либо на перерыве, либо на полу (назначен на стол). Навыки имеют основной или второстепенный тип в зависимости от сложности обучения.

Какие сотрудники были на полу 80 и более минут? (Они должны на перерыв)На какие открытые таблицы я могу назначить этого сотрудника в зависимости от его квалификации?Мне нужен сотрудник, который имеет навык баккара, но еще не назначен в таблицу баккара.Какие сотрудники были за этим столом в течение этого периода времени?Где был этот сотрудник в данный момент?Кто сейчас на смене?Сколько сотрудников на смену может разобраться с Блэкджеком?Сколько сотрудников имеют 3 основных навыка?Какой персонал обладал навыком баккара не менее 3 месяцев?

Эти запросы также могут быть отсортированы по алфавиту или времени, навыку и т. Д.

Я почти уверен, что знаю, как выполнять эти запросы с помощью cypher для neo4j, если правильно моделирую данные. Я не так хорошо разбираюсь в SQL-запросах, я читал, что это может немного усложниться в зависимости от запроса и структуры.

-------------------------------------------------- --------------------------------------

MYSQL Specific

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

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

Для записи данных, таких как список пера / бумаги, каждый день может иметь таблицу со столбцами, начиная с 0000, значение которых увеличивается на 20, вплоть до 2340? До столбцов времени у меня мог быть один столбец для персонала, где каждый сотрудник представлен своим внешним ключом, тогда столбцы времени имели бы внешние ключи для назначенных игровых таблиц, в строке данных должно быть много ячеек, которые не заполняются с тех пор. смена сотрудников не будет 24/7. Если я использую внешние ключи для ссылки на игровые столы, у меня теперь есть проблема, когда сотрудник находится на перерыве? Разве я не рассматриваю первую запись в игровом столе как перерыв?

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

-------------------------------------------------- --------------------------------------

Neo4j Specific

С этими данными у меня будет узел Employee и таблица, у которых есть ребра отношений isA, сопоставленные с фактическими сотрудниками или таблицами? Я полагаю, что с навыками для двух типов мне лучше всего работать с узлом Навыка и устанавливать отношения следующим образом:

ВРЕМЯ
Я испытываю трудности, когда хочу, чтобы эта база данных теперь работала с временной шкалой. Я столкнулся со следующими предложениями для соединения узлов со временем:

Unix Epoch, кажется, общая рекомендация?Подключение узлов к графику год / месяц / день?Хронология Lucene? (Я не знаю много об этом или о том, как с ним работать, некоторые уже упоминали об этом)

И несколько случаев с тем, как соотносятся время и данные:

Персонал меняет дни и время начала / окончания от недели к неделе, это может быть сменный узел со свойствами {shiftStart, shiftEnd, actualStart, actualEnd}, персонал может опаздывать или заболеть во время смены. Будет ли это правильным способом связать каждую смену с сотрудником? Сотрудник (узел) -> Сдвиги (groupNode) -> Сдвиг (узел)

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

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

Именно с запросами у меня возникают проблемы с решением, когда использовать узел или добавить свойство к узлу. Для Сотрудника у него есть имя и идентификационный номер, если бы я хотел найти сотрудника по его идентификационному номеру, было бы лучше иметь его в качестве собственного узла? Это было бы более прямым правом, вместо того, чтобы проверять всех сотрудников на этот уникальный идентификационный номер.

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

-------------------------------------------------- --------------------------------------

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