Category: кино

Category was added automatically. Read all entries about "кино".

вся правда про меня

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

Не тебе судить.
Да, для работы с ленивостью в реальных больших проектах, где условно говоря, много "IO", нужен некоторый опыт. А примеры твои ничего не стоят.
Остальное, в GHC/Haskell, ты откидываешь. И уже вполне приблизился к фанатизму "раз этого нет в любимом инструменте, то это не нужно".
Твои познания за использование ленивости только очень теоретические. Причём, специфической направленности — выискиывать различные fuckup'ы с ленивостью. Вот я тебя спрошу — а приведи примеров хороших и грамотных решений? Ты нормально не ответишь. Зато примеры fuckup'ов привести сможешь.
Ты не разбираешься в теме. Не тебе судить.

rdbms, global id / hosts

А теперь -- о тупой практике вопрос.
Задаю тут, так как знаю, что по крайней мере четверо из читающих меня людей сталкивались с этой проблемой.
Хочется в пределах реляционной базы данных сделать так, чтобы id записей с разных, но подконтрольных мне баз данных не перекрывали друг друга, и при этом могли генерироваться независимо и локально.
Конечная цель -- создавать такие строки таблиц, чтобы таблицы можно было сливать-разливать по необходимости.
Я знаю только два хака для этого.
1. Прямой хак: сделать так, чтобы первичный ключ записи включал в себя (local_id serial, host_id integer) (вариант -- host_name varchar). Хорошо тем, что индекс по (local_id, host_id) в большинстве случаев (для запросов по локальным данным) будет ровно настолько же селективен, как и просто по local_id. Хотя он будет жирнее, что не радует. Ещё больше не радует то, что соединять таблицы придётся по двум полям, внешние ключи тоже будут по двум полям.
1а. Вариант прямого хака: иметь local_id, host_id, но формировать из них уникальную строку (например, тупо, "123.456" для local_id=123 и host_id=456, или более умно, побитово), которую уже считать идентификатором. Нормально, но первичные/внешние ключи по строковым типам обычно медленнее, чем по numeric типам. И вообще, какое-то сомнительное решение.
2. Кривой хак: закодировать host_id в самом id, например, выделяя какие-то биты (старшие/младшие) под host_id, остальные биты оставляя под local_id. Не нравится тем, что этим сильно ограничивается либо диапазон host_id, либо диапазон local_id, и это потребует проверки со стороны программы (либо ошибки со стороны бд), попадает ли новый локально-сгенерированный id в то множество host_id, в которое он должен попадать. А мне нужно для постгреса, а там самый большой целочисленный тип хранит 8 байт, и не уверен, что их хватит в случае таблиц, с которыми будет вестись интенсивная работа. Кроме того, решение хуже тем, что где-то нужно централизованно выдавать host_id, тогда как решение из п.1 с host_name требует только разумной выдачи host_name, такой, чтобы они не пересекались.

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

(думал поставить на этот пост "тематику только для взрослых", но уже запечатал конверт.)