Здравствуйте, ·, Вы писали:

·> У меня все ходы записаны: "отдай дизайнеру, он их ужмёт,". Так что проспись потом приходи и вырази свою мысль, если она есть, твои переобувания в прыжке мало кому интересны.

Но обработанные файлы — это уже новые сущности, которые не заменяют старые. Т.е. есть исходный файл, он лежит в s3 и имеет версию 1, а в базе эти id и версия привязаны к какой-то сущности (или только id без версии, если нужна самая последняя). Дизайнер ужимает файл, заливает его в s3 и появляется версия 2. Если нужна самая последняя версия, то в базе вообще ничего не меняется, т.к. у файла не поменялся id. Если бизнес-логика требует версионирования, то апается версия в соответствии с залитым файлом. При необходимости асинхронно работает сборщик мусора (ибо операция удаления обычно дорогая и бывает дешевле вообще никогда не удалять данные).

Т.е. проблемы с поддержанием целостности тут особо не стоит — файлы иммутабельны, метаинформация о них в базе иммутабельна, работать будет на любой базе.

Здравствуйте, Anton Batenev, Вы писали:

AB>·> У меня все ходы записаны: "отдай дизайнеру, он их ужмёт,". Так что проспись потом приходи и вырази свою мысль, если она есть, твои переобувания в прыжке мало кому интересны.
AB>Но обработанные файлы — это уже новые сущности, которые не заменяют старые. Т.е. есть исходный файл, он лежит в s3 и имеет версию 1, а в базе эти id и версия привязаны к какой-то сущности (или только id без версии, если нужна самая последняя). Дизайнер ужимает файл, заливает его в s3 и появляется версия 2.
Как теперь дизайнер будет объяснять базе, что у файла появилась новая версия и как её связать со старой?

AB>Если нужна самая последняя версия, то в базе вообще ничего не меняется, т.к. у файла не поменялся id. Если бизнес-логика требует версионирования, то апается версия в соответствии с залитым файлом. При необходимости асинхронно работает сборщик мусора (ибо операция удаления обычно дорогая и бывает дешевле вообще никогда не удалять данные).
Молодец, ты изобрёл MVCC.

AB>Т.е. проблемы с поддержанием целостности тут особо не стоит — файлы иммутабельны, метаинформация о них в базе иммутабельна, работать будет на любой базе.
Если иммутабельны, то и по uuid их идентифицировать не нужно, лучше sha2 использовать или типа того.

Здравствуйте, ·, Вы писали:

·> Как теперь дизайнер будет объяснять базе, что у файла появилась новая версия и как её связать со старой?

Ну он же в любом случае заливает новый файл через какую-то админку / веб-интерфейс и т.д. (ибо авторизация, история, аудит и вот это все) — это не должно быть головной болью дизайнера, его задача дизайнить. А уж админка / интерфейс сами справятся с базой.

·> Молодец, ты изобрёл MVCC.

Да как бы этому подходу сто лет как, не я его "изобретатель".

·> Если иммутабельны, то и по uuid их идентифицировать не нужно, лучше sha2 использовать или типа того.

Я вроде явно про uuid не писал, но в качестве идентификатора ты можешь использовать что тебе удобно (twitter вон изобрел snowflake). Правда если ты будешь использовать хэш от содержимого файла (особенно семейство sha), то это будет крайне медленно.

Только S3.

Здравствуйте, Anton Batenev, Вы писали:

AB>·> Как теперь дизайнер будет объяснять базе, что у файла появилась новая версия и как её связать со старой?
AB>Ну он же в любом случае заливает новый файл через какую-то админку / веб-интерфейс и т.д. (ибо авторизация, история, аудит и вот это все) — это не должно быть головной болью дизайнера, его задача дизайнить. А уж админка / интерфейс сами справятся с базой.
Я об этом и говорил, что файлы тут ничем не помогут. Всё равно будет админка и коннект к базе. Файлы тут будут лишь усложнением, которое должно быть оправданным.

AB>·> Молодец, ты изобрёл MVCC.
AB>Да как бы этому подходу сто лет как, не я его "изобретатель".
Это я к тому, что в случае использования субд это у тебя уже будет всё готовое, оттестированное и отлаженное. В случае самопальной реализации можно ВНЕЗАПНО наткнуться на множество граблей.

AB>·> Если иммутабельны, то и по uuid их идентифицировать не нужно, лучше sha2 использовать или типа того.
AB>Я вроде явно про uuid не писал, но в качестве идентификатора ты можешь использовать что тебе удобно (twitter вон изобрел snowflake). Правда если ты будешь использовать хэш от содержимого файла (особенно семейство sha), то это будет крайне медленно.
snowflake это для генерации уникальных id, а я говорю про использование Content-addressable storage, чтобы содержимое файла определяло его id.

Здравствуйте, ·, Вы писали:

·>Здравствуйте, Baiker, Вы писали:

B>>КАК ПРАВИЛО "файлы в базе" не являются такими же "данными", как и записи. Файл — это некая одноразовая/readonly сущность, которая живёт, пока её не затребуют. Каталог фильмов, музыки, фотки сотрудников, рентгены больных... никто такие вещи не меняет без веской причины. Запись — меняют, сам файл — нет.
·>У меня все ходы записаны: "отдай дизайнеру, он их ужмёт,". Так что проспись потом приходи и вырази свою мысль, если она есть, твои переобувания в прыжке мало кому интересны.

Ты сейчас такую тупость спорол, что интернет завял!
"Меняют" — ЧЕРЕЗ МЕХАНИЗМ ПРИЛОЖЕНИЯ, что тут неясного-то?? Т.е. если я из "морды к базе" залил фотку сотрудника, ОЧЕВИДНО я не буду этот файл менять — он просто readonly хрень для показа. А вот если босс скажет, что эти же самые фотки занимают много места, тогда конечно же я их отдам (из файловой системы, дурачок!) простым зипом дизайнеру, он их ужмёт, а потом я точно так же разверну эти файлы на старое место — "морда к базе" даже не заметит изменений! (и СУБД тоже) Вот в чём главный профит. Файлы живут как бы сбоку и МАКСИМАЛЬНО ГИБКО обрабатываются утилитами (если нужно).

Здравствуйте, Anton Batenev, Вы писали:

AB>Но обработанные файлы — это уже новые сущности, которые не заменяют старые

Нет, я как раз топлю за случай, когда НАДО менять файлы. Базе ничего не будет, как был на диске 1.jpg — так и останется. Просто файлы вне базы имеют куда большую гибкость, чем идиотские блобы, бэкапящиеся в терабайтный razderi_menja_jakor'.bak