Предпочтительный метод проектирования баз данных для присвоения пользовательских ролей? (Шляпы по сравнению с Группами)
Вот, пожалуйста:
Используя df в качестве фрейма данных:
df = data.frame(IDNR = 1:3,
start = c("2018-02-15","2017-10-30","2016-02-11"),
end = c("2018-07-01","2018-07-01","2016-12-03"),
exposure = c(0,0,1))
Do:
library(lubridate)
newDF = apply(df, 1, function(x){
newStart = seq(from = ymd(x["start"]), to = ymd(x["end"]), by = 90)
newEnd = c(seq(from = ymd(x["start"]), to = ymd(x["end"]), by = 90)[-1], ymd(x["end"]))
d = data.frame(IDNR = rep(x["IDNR"], length(newStart)),
start = newStart,
end = newEnd,
exposure = rep(x["exposure"], length(newStart)))
})
newDF = do.call(rbind, newDF)
newDF = newDF[newDF$start != newDF$end,]
Результат:
> newDF
IDNR start end exposure
1 1 2018-02-15 2018-05-16 0
2 1 2018-05-16 2018-07-01 0
3 2 2017-10-30 2018-01-28 0
4 2 2018-01-28 2018-04-28 0
5 2 2018-04-28 2018-07-01 0
6 3 2016-02-11 2016-05-11 1
7 3 2016-05-11 2016-08-09 1
8 3 2016-08-09 2016-11-07 1
9 3 2016-11-07 2016-12-03 1
Это создает последовательность дней от start до end на 90 дней и создает с ними меньший фрейм данных вместе с IDNR и exposure. Это действие вернет список фреймов данных, которые вы можете объединить, используя do.call. В последней строке удаляются строки с одинаковыми датами start и end
9 ответов
Я прошел подобную вещь в прошлом году. Там вопрос был: действительно ли мы моделируем наши объекты явно или в общем? В Вашем примере, который означал бы иметь объекты/таблицы как учитель, студент, и т.д. с непосредственными связями между ними или нет.
В конце мы пошли для универсальной модели "Party". Модель Party следующие:
- Сторона представляет человека или организацию;
- Большинство Партийных типов имело зависимую таблицу, чтобы хранить дополнительную информацию в зависимости от партийного типа, например, Человека, Организации, Компании;
- Вещами как Студент или Учитель являются Партийные Роли. У Стороны может быть любое количество Партийных Ролей. Человек может быть и Учителем и Студентом, например;
- Вещи как классы обрабатываются как Партийные Ролевые Отношения. Например, отношения между Учителем и Студенческой ролью указывают на отношения класса;
- Партийные Ролевые Отношения могут иметь подтипы для получения дополнительной информации. Студенческими Учителем Отношениями в Вашей модели является Прием, и это могло иметь дополнительные атрибуты, о которых Вы говорите;
- У сторон нет непосредственных связей друг с другом. Только Партийные Роли касаются друг друга; и
- Для общих группировок информации мы создали представления, если она помогла, потому что SQL может быть немного замысловатым, поскольку отношения являются более косвенными (например, существует три таблицы, промежуточные Партийные объекты для Учителя и Студента).
Это - чрезвычайно мощная модель, та, которая довольно распространена в системах типов CRM. Эта модель в значительной степени прибыла из "Книги Ресурса Модели данных: 1 дюйм Объема, который является превосходным ресурсом для таких вещей.
Действительно ли учителя являются единственным 'человеком', который имеет ставку заработной платы? Можно ограничивать дизайн путем выполнения его этот путь. То, что можно хотеть сделать, имеют таблицу атрибутов, которая хранит дополнительные атрибуты для 'человека'. Это будет допускать будущие модификации.
Группы и модели шляп, которые Вы описываете, конвертируемы, одна к другому. Нет никакого реального беспокойства о потере данных. А именно, таблица "третичных канальных групп" может быть произведена внешними объединениями "таблицы" человека шляпы с различными "таблицами" детали шляпы.
При использовании модели "шляпы", необходимо удостовериться, что данная "таблица шляпы" точно инкапсулирует уникальные характеристики той шляпы. Существует намного меньше прощения там, чем с моделью групп.
Вы, вероятно, захотите настроить несколько представлений для общих задач, если Вы пойдете этим путем - например, если чей-то ввод в поле для "учителя называет", и Вы хотите открыться, некоторые автоматически заполняют, имея представление, которое является в основном
SELECT firstName, lastName
FROM persons
INNER JOIN teachers ON persons.id = teachers.person_id
поможет чрезвычайно.
На тангенциальной ноте одна вещь я нашел, чтобы быть полезным, должен назвать внешние ключи тем же именем как первичный ключ в их исходной таблице. Тем путем Вы можете просто
INNER JOIN original_table USING (primary_key)
в Вашем ОТ вместо monkeying, с ГДЕ или НА эквивалентностях.
Я мог бы изменить учителей на сотрудников и добавить тип сотрудника.
Однако никоим образом форма или форма не были бы я когда-либо хранить электронную почту, адрес, телефон в таблице человека. Они должны все быть отдельными собственными таблицами, поскольку у людей есть несколько адресов электронной почты (работа и домой), несколько номеров телефона (работа, домой, ячейка, факс) и несколько адресов (работа, home1, разместите 2, школа, и т.д.). Я поместил бы каждого в его собственную таблицу и присвоил бы тип ему так, можно определить, который является какой адрес, телефон, и т.д.
Также для адреса, электронной почты, телефона Вы могли бы хотеть, чтобы флаг определил, который является основной записью для использования для контакта сначала. Мы cal наш корреспонденция и это являются булевской переменной, которая усовершенствована триггера как каждый человек, у которого есть запись, должен иметь одну и только одну корреспонденцию, поэтому если это изменяется, старый должен автоматически быть сброшен, а также новый идут в и если это - первая запись, это установлено automaticially и если запись корреспонденции будет удалена, то это будет присвоено другому, если там останутся записями.
да, учителя являются единственными людьми, у которых есть ставка заработной платы как таковая. То поле нужно более точно назвать "classPayRate" - это - особый случай для сотрудников учителя. Сотрудники неучителя отправляют свои общие часы как отдельную позицию в нашей системе начисления заработной платы.
Мне нравится подход Шляпы. В прошлом я реализовал комбинацию шляп и групп. В основном существует список всех возможных действий (полномочия), пользователь может сделать. У меня затем есть таблица групп. У каждой группы могут быть 1 или много действий (полномочия). Я затем присваиваю пользователей группам.
Это предоставляет мне большую гибкость. Я могу получить очень мелкий модуль в своем управлении правами. Я также могу изменить много полномочий народов быстро, просто редактируя группу. На самом деле у меня есть установка страницы управления правами для использования тех же полномочий. Это позволяет конечному пользователю (не меня) устанавливать полномочия для других пользователей.
Для безопасности я предпочитаю использовать Списки Средств управления доступом (ACLs). С ACL у Вас есть Принципалы (пользователи, или группы пользователей), Ресурсы (такие как файл, запись или группа записей) и Действия (такой, как считано, обновите, удалите).
По умолчанию ни у кого нет полномочия. Для предоставления разрешения, Вы добавляете, что запись как Bob имеет Доступ для чтения к Abc Файла.
Необходимо смочь найти код, который помогает Вам реализовать что-то вроде этого. В Java JAAS поддерживает этот метод.
Я использую пакет ACL для мелкомодульных полномочий на сайте - основа моего вопроса больше о том, как сохранить метаданные для людей, которые имеют различные роли и встраивают несколько гарантий в систему для целостности данных (таким образом, что человек должен сделать, чтобы учитель записал, чтобы быть установленным как учитель класса - ограничение внешнего ключа ссылается на таблицу учителя, не таблицу человека).
Раньше я использовал модель Party . Я действительно исправляю большинство недостатков.