Градиентный спуск всегда сходится из любой начальной точки (если сходится), но требует больше итераций. Метод Ньютона требует примерно на порядок меньше итераций, но может расходиться. Существуют гибридные способы поиска экстремума, где сначала применяется градиентный спуск, а после (в локальной области) — метод Ньютона, что позволяет уменьшить количество итераций до сравнимого с методом Ньютона, обеспечив сходимость.
Boolean использовать в полях базы данных можно и нужно, и вот почему:
Встроенные примитивные типы данных хорошо индексируются, причем, сами индексы занимают не так много места. Обеспечивается высокая скорость доступа к данным. Это может быть не очень заметно поначалу, когда пользователей немного. Но как будет работать SELECT * FROM users WHERE... с вашей вложенной структурой, если посльзоватетелей 10 миллионов? А если таких запросов 10 в секунду? Конечно, можно проиндексировать и вложенную структуру, но тут уже хранение индексов будет дороже, и скорость upd/ins/del существенно ниже при большей нагрузке на сервер.
Что же касается дополнительных полей, действительно, лучше добавить нужное поле в таблицу и соответствующий триггер, проверяющий при update/ insert логическую связность и непротиворечивость полей. А еще лучше, добавить связанную таблицу со всеми необходимыми полями, такими как текущий статус, время его обновления, кем обновлен, и хранить там историю обновлений, если необходимо. Поля в этой таблице тоже можно добавлять, по мере необходимости, а если потребуется, добавить еще одну связанную таблицу.
Это и есть одна из инженерных концепций релятивистских баз данных.
"Минуй нас пуще всех печалей и барский гнев, и барская любовь!"
Грибоедов А. С. "Горе от ума".
Градиентный спуск всегда сходится из любой начальной точки (если сходится), но требует больше итераций. Метод Ньютона требует примерно на порядок меньше итераций, но может расходиться. Существуют гибридные способы поиска экстремума, где сначала применяется градиентный спуск, а после (в локальной области) — метод Ньютона, что позволяет уменьшить количество итераций до сравнимого с методом Ньютона, обеспечив сходимость.
Да, смешно получилось) К ночи бывает. Встречались и "триногометрия", и "чем больше градусов, тем меньше косинусов")
Конечно же, " реляционных баз данных")
Boolean использовать в полях базы данных можно и нужно, и вот почему:
Встроенные примитивные типы данных хорошо индексируются, причем, сами индексы занимают не так много места. Обеспечивается высокая скорость доступа к данным. Это может быть не очень заметно поначалу, когда пользователей немного. Но как будет работать SELECT * FROM users WHERE... с вашей вложенной структурой, если посльзоватетелей 10 миллионов? А если таких запросов 10 в секунду? Конечно, можно проиндексировать и вложенную структуру, но тут уже хранение индексов будет дороже, и скорость upd/ins/del существенно ниже при большей нагрузке на сервер.
Что же касается дополнительных полей, действительно, лучше добавить нужное поле в таблицу и соответствующий триггер, проверяющий при update/ insert логическую связность и непротиворечивость полей. А еще лучше, добавить связанную таблицу со всеми необходимыми полями, такими как текущий статус, время его обновления, кем обновлен, и хранить там историю обновлений, если необходимо. Поля в этой таблице тоже можно добавлять, по мере необходимости, а если потребуется, добавить еще одну связанную таблицу.
Это и есть одна из инженерных концепций релятивистских баз данных.