Пол , наконец... (оригинальный)

Хм) Тайланд делает чудеса

ОРИГИНАЛЬНЫЙ пол.

ИСХОДНЫЙ

Ха) Кто ж разберет этот пол) В общем, все сводится к тому, что у меня есть набор уникальных данных пациента (которые я считаю на текущий момент просто идентификатором), которые могу или держать в дополнительной таблице и иметь внешние ключи, или просто на уровне сервера генерировать или находить uuid и не создавать доп таблицы и попрощаться в внешними ключами

Только учти, что пациенты - это только малая часть. Там до черта всего нужно по такой же схеме версионировать

Ты по-моему непробиваем...

Нахера тебе прощаться с внешними ключами?

Кроме усложнения схемы и дополнительных дублированных данных причин нет

Если ты правильно спроектируешь БД, у тебя будет всё ОК с FK.

Кроме усложнения схемы и дополнительных дублированных данных причин нет

ПРимер усложнения и дублирования.

ПРимер усложнения и дублирования.

1 вариант. Table patient (patid serial pk), table patcard (patid int, stamp timestamp, (patid, stamp) - pk, patid - fk) 2 вариант. Table patcard (patid uuid, stamp timestamp, (patid, stamp) - pk)

Делай вариант 1, в чём усложнение-то?

Вставить ещё одну запись усложнение?

Лишние данные. Речь, повторю, не только про пациентов и карточки. Там много таблиц будет иметь дубль с идентификаторами.

Увы, тебе придётся делать сложную структуру, если у тебя temporal data...

Да, таблиц будет в 1.5. примерно раза больше.

в чём сложность — всё равно не понятно.

У тебя там на всю эту хрень будет таблиц 100-200 всего.

Это не очень и большая БД.

@MasterZiv спасибо за совет и мнение! Я обдумаю, что ты мне сказал

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

лучший комментарий по теме

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

event sourcing

но мне кажется, это не ваш случай

Опасно. Но это зависит от твоей архитектуры приложения, потому как может у тебя там 20 проверок перекрёстных по данным до того, как всё это попадает в БД...

Что опасного-то?

Что опасного-то?

А чё ты спрашиваешь, сам всё знаешь...

event sourcing

да, это не совсем мой случай

А чё ты спрашиваешь, сам всё знаешь...

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

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

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

давайте выясним, откуда он вощьмется

этот самый несуществующий ключ

только из фатальной ошибки в коде, больше не откуда

а если такая ошибка есть, то вряд ли от нее защитит внешний ключ (хотя есть шанс, да)

кому придет в голову умножать автоинкремент на два, скажем?

куда вероятнее что малолетний хацкер будет посылать в апи все что попало

и здесь ему без разницы, нуллы пихать или существующие документы

ну, это решается валидацией входных данных в хранимках

вам нужна AI-complete хранимка, чтобы отследить баловство

Ну для начала достаточно на уровне хранимки проверки прав доступа пользователя и проверки, что он обращается к доступным ему данным.

ну вообще это все конечно в приложении должно быть

но я про то, что всё это борьба с не очень детерминированными штуками, против которых внешние ключи представляют частичную защиту

Я согласен, внешние ключи - это просто ещё один пункт защиты из многих.

@etkee спасибо за обсуждение и советы

Я согласен, внешние ключи - это просто ещё один пункт защиты из многих.

В твоём случае они ещё и защита от дурацкого дизайна базы?

В твоём случае они ещё и защита от дурацкого дизайна базы?

Я помню, что ты на другом плече)) завтра утром попробую понять, у кого из вас рожки, а у кого нимб

Главное помни, что душа твоя родная, и бессмертная, одна!

лучший комментарий по теме

меня за него банить хотел чел

ну да, мог бы за отсутствие восприимчивости к сарказму предложить

Select null Но как выше заметили, зачем вообще использовать else... ?

Пасиб. Интересовало именно наличие какой-то управляющей директивы. И еще вопросец: Чего почитать, чтобы ебашить свободно запросы размером с А4. А то какие-то простенькие джойны могу, а вот когда речь заходит о подсчетах интервалов и прочем дерьме, я упираюсь в собственное невежество.

Пасиб. Интересовало именно наличие какой-то управляющей директивы. И еще вопросец: Чего почитать, чтобы ебашить свободно запросы размером с А4. А то какие-то простенькие джойны могу, а вот когда речь заходит о подсчетах интервалов и прочем дерьме, я упираюсь в собственное невежество.

Мартин ГРабер

Мартин ГРабер

Если есть, залей плз в чатик.

http://specfx.narod.ru/books/SQL_M_Gruber.pdf

Эта?

https://medium.com/fuzzy-sharp/migrating-to-postgres-2dc1519a6dc7

Эта?

Эта.

http://specfx.narod.ru/books/SQL_M_Gruber.pdf

Только поищи издание как можно более позднее, их было штуки 3.

https://msdn.microsoft.com/en-US/library/ff877884(SQL.120).aspx от скольки нод это реально работает, кто пробовал?

от двух

некоторые деятели даже умудряются без АД запилить

https://www.sqlpassion.at/archive/2016/01/11/how-to-create-a-sql-server-availability-group-without-an-active-directory-domain/

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

Можете ещё раз и более детально?

таблица: client, status, dt status имеет два значения надо получить: client, end_dt, start_dt

проблема в том, что может быть такие записи: client1, status1, dt1 client1, status0, dt2 client1, status1, dt2 client1, status0, dt3 из которых надо получить: client1, dt1, dt3

а может быть такие записи: client1, status1, dt1 client1, status1, dt2 client1, status0, dt2 client1, status1, dt3 из которых надо получить: client1, dt2, dt3

Похоже на задачу gaps and islands

в mysql удалил несколько партиций у таблички. как теперь освободить место на диске ? OPTIMIZE TABLE zabbix.history_log; так ?

а может быть такие записи: client1, status1, dt1 client1, status1, dt2 client1, status0, dt2 client1, status1, dt3 из которых надо получить: client1, dt2, dt3

не понял принцип формирования результата, условия точно описаны верно?

некоторые деятели даже умудряются без АД запилить

эт 16, а у меня 14 должен быть

14 и 16 - отличия минимальны. не помню сейчас в чем.

но они реально не большие

не понял принцип формирования результата, условия точно описаны верно?

я вот тоже не понимаю, пойду дальше осмысливать...

похоже на очередную фигню от аналитиков

короче, если надо игнорировать записи с новым статусом, идентичным предыдущемум

то просто создается новая колонка status_changed (bool)

и как её формировать запросом? мне не надо таблицу, мне нужно просто выгрузить

А, я предполагал заполнять ее при вставке. Ну подзапросом как минимум :shruggie:

который будет с having?

я предполагал фильтровать записи по where not exists и получить cte/view из исходной таблицы

а каким боком ты проверишь прошлый статус?

select * where client = this.client and dt < this.dt order by dt desc limit 1

тот же having почти...

хотя да, тут чуть посложнее чем exists

вот данные, мне по клиенту 2 надо получить две строчки: 2, 2016-10-05 16:15:43, 2016-10-05 17:45:40 2, 2017-08-03 10:21:59, 2017-08-03 14:30:22

блин, кажись догнал

2 -> 3 -> 2?

если в лоб, то берем все 3, находим предыдущие 2, находим последующие 2, так или иначе убираем дубликаты

вот да, я тоже так подумал

если нужно убрать дубликаты и версия ниже 5.6 можно попробовать alter table add unique ignore

с чего решили, что у меня mysql =))