Сообщение Re[3]: Внешние ключи: предпочтения от 30.12.2021 21:02
Изменено 30.01.2022 19:05 RushDevion
Re[3]: Внешние ключи: предпочтения
XZ>
XZ>Ещё оптимизаторы performance любят везде with(nolock) использовать — тоже, говорят, ускоряет.
Для мониторинга и грубой аналитики это имеет право на жизнь.
XZ>Есть же принцип — "в БД находятся только валидные данные".
Ню-ню. Логи в базу ни разу не складывали?
А слабоструктурированные данные?
И вот не надо про ELK, NoSQL и т.п. Бывает так, что решение уже есть, оно тормозит, а времени на переписать по уму никто не даст.
И, кстати, многие NoSQL как-то обходятся без внешних ключей.
XZ>Ну и смысл использовать БД тогда? Ещё быстрее будет просто в файлах хранить записи.
И транзакционку самим обеспечивать, а индексы руками строить? Оно, может и будет быстрее, но точно не в смысле времени на разработку.
А ещё бывают append-only схемы. Взять тот же event sourcing как вырожденный вариант.
А ещё бывает OLAP-like отчёты, прилепленные к изначально OLTP базе (или к ее реплике)
В общем, я ни к тому, что нужно сейчас же пойти и прибить все внешние ключи в БД
А к тому, что пользоваться ими или нет — зависит от целей и задач.
Таки посмеялся, спасибо.XZ>Вопрос кандидату на должность секретарши:
XZ>- Вы и правда набираете на компьютере со скоростью 600 знаков в минуту?
XZ>- Правда. Но такая фигня получается...
XZ>Ещё оптимизаторы performance любят везде with(nolock) использовать — тоже, говорят, ускоряет.
Для мониторинга и грубой аналитики это имеет право на жизнь.
XZ>Есть же принцип — "в БД находятся только валидные данные".
Ню-ню. Логи в базу ни разу не складывали?
А слабоструктурированные данные?
И вот не надо про ELK, NoSQL и т.п. Бывает так, что решение уже есть, оно тормозит, а времени на переписать по уму никто не даст.
И, кстати, многие NoSQL как-то обходятся без внешних ключей.
XZ>Ну и смысл использовать БД тогда? Ещё быстрее будет просто в файлах хранить записи.
И транзакционку самим обеспечивать, а индексы руками строить? Оно, может и будет быстрее, но точно не в смысле времени на разработку.
А ещё бывают append-only схемы. Взять тот же event sourcing как вырожденный вариант.
А ещё бывает OLAP-like отчёты, прилепленные к изначально OLTP базе (или к ее реплике)
В общем, я ни к тому, что нужно сейчас же пойти и прибить все внешние ключи в БД
А к тому, что пользоваться ими или нет — зависит от целей и задач.
Re[3]: Внешние ключи: предпочтения
XZ>
XZ>Ещё оптимизаторы performance любят везде with(nolock) использовать — тоже, говорят, ускоряет.
Для мониторинга и грубой аналитики это имеет право на жизнь.
XZ>Есть же принцип — "в БД находятся только валидные данные".
Ню-ню. Логи в базу ни разу не складывали?
А слабоструктурированные данные? Аудит какой-нибудь.
И вот не надо про ELK, NoSQL и т.п. Бывает так, что решение уже есть, оно тормозит, а времени на переписать по уму никто не даст.
И, кстати, многие NoSQL как-то обходятся без внешних ключей.
XZ>Ну и смысл использовать БД тогда? Ещё быстрее будет просто в файлах хранить записи.
И транзакционку самим обеспечивать, а индексы руками строить? Оно, может и будет быстрее, но точно не в смысле времени на разработку.
А ещё бывают append-only схемы. Взять тот же event sourcing как вырожденный вариант.
А ещё бывает OLAP-like отчёты, прилепленные к изначально OLTP базе (или к ее реплике)
В общем, я ни к тому, что нужно сейчас же пойти и прибить все внешние ключи в БД
А к тому, что пользоваться ими или нет — зависит от целей и задач.
Таки посмеялся, спасибо.XZ>Вопрос кандидату на должность секретарши:
XZ>- Вы и правда набираете на компьютере со скоростью 600 знаков в минуту?
XZ>- Правда. Но такая фигня получается...
XZ>Ещё оптимизаторы performance любят везде with(nolock) использовать — тоже, говорят, ускоряет.
Для мониторинга и грубой аналитики это имеет право на жизнь.
XZ>Есть же принцип — "в БД находятся только валидные данные".
Ню-ню. Логи в базу ни разу не складывали?
А слабоструктурированные данные? Аудит какой-нибудь.
И вот не надо про ELK, NoSQL и т.п. Бывает так, что решение уже есть, оно тормозит, а времени на переписать по уму никто не даст.
И, кстати, многие NoSQL как-то обходятся без внешних ключей.
XZ>Ну и смысл использовать БД тогда? Ещё быстрее будет просто в файлах хранить записи.
И транзакционку самим обеспечивать, а индексы руками строить? Оно, может и будет быстрее, но точно не в смысле времени на разработку.
А ещё бывают append-only схемы. Взять тот же event sourcing как вырожденный вариант.
А ещё бывает OLAP-like отчёты, прилепленные к изначально OLTP базе (или к ее реплике)
В общем, я ни к тому, что нужно сейчас же пойти и прибить все внешние ключи в БД
А к тому, что пользоваться ими или нет — зависит от целей и задач.