Таблицам ссылки нужно бессмысленное поле первичного ключа?
Вы можете определить свою собственную функцию, а затем использовать ее в инструкции dplyr mutate следующим образом:
df %>% group_by() %>%
mutate(
cumsum_10 = cumsum_with_reset(value, 10),
group_10 = cumsum_with_reset_group(value, 10)
) %>%
ungroup()
Функция cumsum_with_reset() принимает столбец и пороговое значение, которое сбрасывает сумму. cumsum_with_reset_group() аналогичен, но идентифицирует строки, которые были сгруппированы вместе. Определения следующие:
# group rows based on cumsum with reset
cumsum_with_reset_group <- function(x, threshold) {
cumsum <- 0
group <- 1
result <- numeric()
for (i in 1:length(x)) {
cumsum <- cumsum + x[i]
if (cumsum > threshold) {
group <- group + 1
cumsum <- x[i]
}
result = c(result, group)
}
return (result)
}
# cumsum with reset
cumsum_with_reset <- function(x, threshold) {
cumsum <- 0
group <- 1
result <- numeric()
for (i in 1:length(x)) {
cumsum <- cumsum + x[i]
if (cumsum > threshold) {
group <- group + 1
cumsum <- x[i]
}
result = c(result, cumsum)
}
return (result)
}
# use functions above as window functions inside mutate statement
df %>% group_by() %>%
mutate(
cumsum_10 = cumsum_with_reset(value, 10),
group_10 = cumsum_with_reset_group(value, 10)
) %>%
ungroup()
12 ответов
Для настоящих таблиц ссылок они обычно не существуют как объектные сущности в моих объектных моделях. Таким образом, суррогатный ключ никогда не используется. Удаление элемента из коллекции приводит к удалению элемента из связи, в которой известны оба внешних ключа ( Person.Siblings.Remove (Sibling) или Person.RemoveSibling (Sibling) , который надлежащим образом переводится на уровне доступа к данным как usp_Person_RemoveSibling (PersonID, SiblingID) ).
Как упоминал Майк, если он действительно станет реальной сущностью в вашей объектной модели, тогда он может быть достоин ID. Однако, даже с добавлением временных факторов, таких как эффективные даты начала и окончания отношений и тому подобное, это не всегда ясно. Например, у коллекции может быть дата вступления в силу, связанная на агрегированном уровне, поэтому сама связь может все еще не стать сущностью с какими-либо открытыми свойствами.
Я хотел бы добавить, что вам может потребоваться таблица, проиндексированная как способов на двух столбцах внешнего ключа.
Я бы использовал составной ключ, а не лишний бессмысленный ключ.
Я бы не использовал систему ORM, которая применяет такие правила в моей структуре БД.
Наличие одного столбца pk может помочь в ситуации аварийного восстановления. Так что, хотя в теории правильно, что вам нужны только 2 внешних ключа. На практике, когда дерьмо попадает в вентилятор, вам может понадобиться один столбец ключа. Я никогда не был в ситуации, когда меня ввернули, потому что у меня был идентификатор одного столбца, но я был в тех, где меня ввернули, потому что я этого не сделал.
Я использовал составной ключ, чтобы предотвратить повторный ввод и позволить базе данных обрабатывать исключение. Используя один ключ, вы полагаетесь на интерфейсное приложение, которое проверяет базу данных на наличие дубликатов перед добавлением новой записи.
Если вы используете ORM для получения / изменения данных, для некоторых из них требуется первичный ключ из одного столбца (спасибо Тому Ху за указание на это) для правильной работы (я считаю, что Subsonic 2.x был таким образом, не уверен насчет 3.x).
По моему мнению, наличие первичного ключа никак не влияет на производительность, поэтому я обычно использую его.
Я (почти) всегда использую дополнительный одностолбцовый первичный ключ. Как правило, это облегчает создание пользовательских интерфейсов, потому что, когда пользователь выбирает эту конкретную связывающую сущность, я могу идентифицировать одно целочисленное значение, а не создавать и затем анализировать составные идентификаторы.
Если это настоящая таблица соединения «многие ко многим», то выгрузите ненужный столбец идентификаторов (если ваша ORM требует этого. В этом случае вам нужно решить, будет ли ваш интеллект превзойти вашу практичность).
Но я считаю, что настоящие таблицы соединения довольно редки. Обычно незадолго до того, как я начинаю хотеть помещать в эту таблицу другие данные. По этой причине я почти всегда моделирую эти объединяемые таблицы как объекты с самого начала и вставляю туда идентификатор.
If you need to traverse the join table 'in both directions', that is starting with a table1fk or a table2fk key only, you might consider adding a second, reversed, composite index.
ADD KEY ('table2fk', 'table1fk')
Правильный ответ:
- Первичный ключ -
('table1fk', ' table2fk ') - Другой индекс на
(' table2fk ',' table1fk ')
Потому что:
- Вам не нужен только индекс для table1fk или table2fk: оптимизатор будет использовать PK
- Скорее всего, вы будете использовать таблицу «обоими» способами
- Добавление суррогатного ключа необходимо только из-за безумных ORM
Есть что-то, что называется отношениями идентификации и неидентификации. При идентификации отношений FK является частью PK в таблице «многие ко многим». Например, предположим, что у нас есть таблицы Человек , Компания и таблица «многие ко многим» Занятость . В идентифицирующем отношении оба fk PersonID и CompanyID являются частью pk, поэтому мы не можем повторить комбинацию PersonID, CompanyID .
TABLE Employment(PersonID int (PK,FK), CompanyID int (PK,FK))
Теперь предположим, что мы хотят зафиксировать стаж работы, чтобы человек мог покинуть компанию, поработать в другом месте и вернуться в ту же компанию позже. Здесь связь не идентифицирует, комбинация PersonID, CompanyID теперь может повторяться, поэтому таблица будет выглядеть примерно так:
TABLE Employment(EmploymentID int (PK), PersonID int (FK), CompanyID int (FK),
FromDate datetime, ToDate datetime)
Я использовал оба, единственное преимущество использования первой модели (с uid) состоит в том, что вы можете переносить идентификатор как число, тогда как в некоторых случаях вам придется сделать некоторые конкатенация строк с составным ключом для ее передачи.
Я согласен, что не индексировать внешние ключи - плохая идея, какой бы путь вы ни выбрали.