Коллеги, друзья, любители печенек.. у меня вопрос, и я решил проконсультироваться с Вами.
Имеем: SQL и таблица данных (ID, Name) в ней 40 млн записей.
Необходимо к каждой записи привязать данные (примерно 100 записей к каджой из 40 млн).
Характер данных: структурированные данные (ID, DATE, DATA)

Внимание вопрос: как правильнее выбрать решение
1) Таблица, в которой будет 4 миллиарда записей (4*100)
2) В первой таблице создать поле blob и хранить данные в текстовом виде (понимаю, что о фильтрации можно будет забыть)
3) Пойти по пути 1с, котрые вынесли журнал ренистрации пользоватлей, в текстовый документ и при необходимости бегать по нему.

Эти данные могу понадобиться, а могу и нет (по запросу)
Может кто-то решал подобную задачу. Спасибо.

(0) я за 1 вариант

(0) Ты ничего не сказал, что могло бы определить выбор
Не привел ни одного примера использования, кроме "Эти данные могу понадобиться, а могу и нет"

Хотя (1) это не помешало сделать выбор

(2) Согласен, в первой таблице Заказ-Наряд, во второй таблице записи с действиями, которые сотрудник проделал, чтобы выпонить этот заказ.
Поэтому я и написал про аналог журнала регистрации 1с

(3) Вопрос логичности, скорости роста БД, так как данные по Заказ-Наряд создаются очень активно.

(0) для нормальной СУБД на нормальном серваке - 4 млрд записей индексированных - Обычная работа

(6) Да, согласен. Но какие минусы, если бы я выбрал хранение в BLOB, я бы сэкономил на месте (на размерах бд) ?

(7) не факт
а производительность точно ниже.

Не понимаю, а почему не сделать 2 таблицы, как и принято в реляционных базах - заказ-наряды и действия по ним?

(9) Потому что, 4 млрд записей это за 1 год, а что будет дальше? Например 10 млрд...
Логичнее было бы спросить - отдельная таблица, это единственное верное решение?

(10) если тебя смущает размер базы - то не парься для снижения дисковой нагрузки есть варианты - например использование разных файловых групп для разных таблиц

(4) Конечно же действия отдельно
И вопросы производительности здесь вообще не определяющи и притянуты за уши

(0) Объясни, в чем проблема? Почему нужно выбирать, и что нужно экономить? У тебя недостаточно свободного места на сервере, или что?
Самое правильное решение - вторая таблица.
Если с этим у тебя возникают какие-то проблемы, то их нужно решать отдельно, а не выбирать компромиссы.

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

(14) Сакральный смысл прост
В журнал регистрации пишется как когда транзакция удалась, так и когда нет
А в базу можно писать только когда транзакция удалась

Принято, спасибо за ответы.

(15)> в этом был же какой-то сакральный смысл.
Смысл в том, чтобы хранить логи отдельно. Ты можешь это интегрировать с общей системой хранения логов. Ты можешь прикрутить туда свою систему ротации логов. Основная идея здесь в том, чтобы хранить логи так как это делает весь остальной мир - отдельно и в текстовом файле.

(15) Можно же было разделить "прикладной" журнал регистрации и "системный". Про транзакции писать в системный, а про то, что произошло в базе - в прикладной, хранящийся внутри базы.

(0) Если версия SQL позволяет использовать сжатие данных - оно в разы может сэкономить место.