Вот вариант ответа, в ктором говорится, что значения NULL может занимать 1.75%, https://stackoverflow.com/questions/37144363/null-...
Также, если говрить в контексте одной ячейки, то NULL значение в какой-либо ячейке занимает ничего. А для обозначения NULL/NOT NULL требуется всего один бит. VARCHAR (не NULL) предположительно занимает 1 байт минимум (либо терминальный байт в пустой строке, либо длина строки). Поэтому при прочих равных NULL выгоднее.
Ничего сложного нет: просто создаете отдельный pv и монтируете его в два различных pod. Если не понятно чкак это, то читайте все концепты в оф документации.
Как верно вам указали, уравнение движения - это диф. ур. Разница в том, что при можедировании на ПК приращения конечные. Из-за конечности приращений нужно внимательно смотреть на возможную потерю точности.
select t.*
from
(
select ROW_NUMBER() OVER (PARTITION BY m.city) limit_num, m.*
from my_table m
) as t
join cities c
on c.city = t.city and t.limit_num <= c.num_rows_required;
1. Индекс это сбалансированное дерево. Если не ошибаюсь, то скорость обнолвения дерева зависит от его высоты. Высота дерева индекса обычно небольшая. Поэтому обновления индексов проходят очень быстро "в онлайне" и при OLTP-нагрузках это ок.
2. Да, но рост времени логарифмический. Я бы рекомендовал посмотреть в сторону table partitioning. Там и индексы будут "локальными" и будут расти только в пределах одной партиции. И управляемость таблицей будет выше.
PS. Не могу гарантировать что мое мнение полностью соответсвует реальному положению дел. Все покажет только тестирование.
NataDori, а сами не можете сгенерировать? Вам же эксперимент нужно будет поставить, наверно? Может быть, покажете на защите в онлайне, как заходите в БД какую-либо с левого ip. Обсудите с преподавателем, anyway.
Yurist90, Исходите из издержек. Сколько вам сэкономят работы по улучшению сайта, добавлению фич/исправлению ошибок, допустим за год, вот из этой годовой суммы какую-то часть выплатите.
Инициативы по развитию могут исходить только от клиентов. От программиста могут исходить технические инициативы в плане исполнения чего-либо и только. И это не влияет на продажи, это влияет на издержки. Хорошее решение: меньше вычислительной мощности нужно, более легко вносить изменения в проект, меньше трудозатраты, ниже издержки. Никакой связи с продажами.
