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

Gt_>угу. т.е. на проверку целостность вовсе не субд обеспечивает, а алгоритмы.

И субд и алгоритмы. Там где можно воспользоваться возможностями субд мы от этого вовсе не отказываемся. Зачем изобретать велосипеды? Отказ от транзакций происходит только, если это не возможно в принципе. Например, если данные генерируются разными процессами в разное время. Снятие флага CHECK CONSTRAINT с FK делается в основном из соображений производительности. Например, partition switching позволяет переносить данные из одной таблицы в другую в одно мгновение. В то время как обычный INSERT INTO и DELETE занимает в общей сложности минут 40. Стоит такая экономия усложнения обеспечения целостности, если учесть, что это только один из способов сэкономить?

Gt_>обычно дальше идет вопрос, а правильно ли тогда использовать субд, если с определенных объемов уже ни целостность ни транзакционность не применить.

По-твоему, субд — это только целостность и транзакционность?

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

Gt_>угу. т.е. на проверку целостность вовсе не субд обеспечивает, а алгоритмы.

И субд и алгоритмы. Там где можно воспользоваться возможностями субд мы от этого вовсе не отказываемся. Зачем изобретать велосипеды? Отказ от транзакций происходит только, если это не возможно в принципе. Например, если данные генерируются разными процессами в разное время. Снятие флага CHECK CONSTRAINT с FK делается в основном из соображений производительности. Например, partition switching позволяет переносить данные из одной таблицы в другую в одно мгновение. В то время как обычный INSERT INTO и DELETE занимает в общей сложности минут 40. Стоит такая экономия усложнения обеспечения целостности, если учесть, что это только один из способов сэкономить?

Gt_>обычно дальше идет вопрос, а правильно ли тогда использовать субд, если с определенных объемов уже ни целостность ни транзакционность не применить.

По-твоему, субд — это только целостность и транзакционность? И какие альтернативы?