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

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

Основные данные

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

Работник

- Идентификационный номер

- Название

- Навыки (Блэкджек, Баккара, Рулетка и т. Д.)

Таблица

- Идентификационный номер

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

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

Возможные Запросы

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

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

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

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

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

MYSQL Specific

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

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

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

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

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

Neo4j Specific

С этими данными у меня есть сотрудник и узел таблицы, которые имеютэто" Отображение границ отношений с фактическими сотрудниками или таблицами? Я полагаю, что с навыками для этих двух типов мне лучше всего работать с узлом Skill и устанавливать такие отношения? Блэкджек->ISA->Умение, Сотрудник->hasSkill->Блэкджек, Стол->typeIs->Блэк Джек?

ВРЕМЯ

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

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

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

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

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

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

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

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

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

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