Дык вышел уже один сезон возражденного Стар Трека — Star Trek: Discovery. Причем закончился сезон интригующе — объявился Enterprise.
но как по мне, то лучшее что выходило из фильмов-сериалов про космос за последние 2-3 года — это Expanse
тут есть еще одна проблема — на данный момент нету единого платного ресурса на котором можно было смотреть все популярные сериалы. как результат — что бы смотреть любимые сериалы надо иметь не одну платную подписку
когда появится — тогда в серьез задумаюсь над подпиской на таком ресурсе, а пока — пиратствуем
Скорее речь идет об изоляции. То есть программируя на объектно-ориентированных языках мы почему-то свято чтим наследование-инкапсуляция-полиморфизм, и инкапсулируем сложность «под капот», всеми силами обеспечиваем слабую связность. Но когда дело доходит до баз данных это внезапно куда-то пропадает, и становится совершенно нормальным размазать одну логическую единицу тонким слоем от кода и до хранимок в БД, вместе с триггерами и джобами.
рискну предположить (хотя случаи могут быть разными) — все это размазывание было проведено в ходе N-го количества оптимизаций со стороны базы данных. Дело в том, что я многократно наблюдал как при написании логики в базе данных пытались использовать часть принципов ООП — оно все хорошо, красиво, удобно, проще поддерживать… НО, рано или позно приходят они… тормоза…
То ли это какой-то отчет использующий очень навороченую вьюху на все случаи жизни, в которой есть все что нужно и не нужно париться и особо мудрить. Или же это какая-то аггрегация которая использует функции для каких-то вычислений, в которые упрятанна с глаз долой забористая логика. И все, приехали, вариант один — разворачивать функции-вьюхи, выкидывать все ненужное, а все нужное писать так что бы было максимально быстро. вот после таких оптимизаций логика реализованая в БД может быть весьма тяжело читаемой.
Впрочем, причины могут быть и более тривиальные — в целях экономии времени в процедуру\функцию\триггер вставляют if else с нужным кодом, вместо того что бы переписать процедуру под новые требования. И со временем почти вся процедура слеплена из таких кусков, и без вдумчивого дебага уже непонять что там происходит. Но почему такое происходит не загадка — лень и дедлайны, на то что бы сделать по нормальному, а потом еще и провести хорошее тестирование может потребоваться слишком много времени. Справделивости ради стоит сказать что такое характерно и для ООПшных языков программирования.
В общем, возвращаясь к исходной точке — для БД либо шашечки, либо ехать (либо принципы ООП, либо скорость выполнения)
З.Ы. это моя ИМХА за 13 лет собраная на своем и опыте коллег
из того что я наблюдал — при наборе некоторой критической массы (размера базы данных или размера критичных таблиц), все равно часть (да, не всё, но какие-то части) кода коротрый генерится ORM заменяется на хранимые процедуры. И я не вижу в этом вообще ничего плохого. Потому что код который был сгенерен ORM не использует все возможности диалекта SQL используемой СУБД, а частенько попросту паршив, просто это не чувствуется на малых данных.
ну и еще нанимают ДБА или SQL разработчика, потому что <подставьте язык сами> разрабочики плохо знают тонкости используемой на проекте СУБД, а бывает что и вовсе разучились SQL запросы писать.
Так что учитывать интересы базы рано или поздно придется, от этого никуда не уйти, но тут важно найти разумный компромис.
ну вот что-то мне кажется что вам как и мне повезло с конституцией или метаболизмом (или еще с чем) — у меня вес вообще сложно набирается, сейчас около 75 (при росте 1м82). до этого долго держался в районе 70 — жена немного меня откормила :)))
тоже питаюсь как попало — обычно не завтракаю, уже на работе чего-то к утренему чаюберу, ужин у меня вобще с 20 до 22.
правда я много ем сезонных (или не очень сезонных) фруктов.
из спорта я для себя 4 года назад выбрал фехтование — качалки для меня слишком унылы, груповые виды спорта тоже не для меня. в прицнипе удалось поставить себя на регулярные занятия, хотя иногда все же бывают простои в 1-2 месяца, но стараюсь этого недопускать — на результатах сильно сказывается.
банки и госуха очень медленно переходят на новые версии виндов.
а в таких случаях у них наверняка есть контракт с МС на расширеную поддержку для тех продуктов, для которых у МС уже закончился срок поддержки.
так что я думаю еще спокойно себе не один год смогут сидеть на вин 7\8 пока соответствующий софт под 10 винду не допилят
помимо брата, у меня у бывших сотрудников корповые телефоны на винде были — так что я всякого успел наслушаться от тех кто сменил телефон с вин8.1 на вин10 :)))
багов было просто немерянно. ни о какой стабильной работе и речи не было по крайней мере первые пол года — у меня брат брал одну из первых моделей нокии на вин10, много плевался. потом вроде стало получше, но все равно багов хватало.
но вообще да, мне тоже обидно что свернули, я мобильной вин8.1 был очень даже доволен.
да, был такой Мидас — согласно вики фригийский царь
за windows mobile конечно обидно. версия 8.1 вполне себе годная, я лично доволен был — но у меня не завышеные потребности, все что мне нужно в ней было. а с мобильной 10-й фейл конечно полнейший получился, поэтому не удивительно что решили свернуть.
а поправьте меня пожалуйста, если я ошибаюсь и неправильно понял суть статьи.
установленые левые корневые сертификаты лишь дают возможность выдавать левые сайты за довереные, но не дают возможность например читать мой трафик с gmail? я правильно все понимаю или чего-то не понял из статьи?
я просил про журнал транзакций указать в чем я неправ.
а в ответ — перевод темы на индексы и очевидные рассказы что все нужно проверять на тестовом стенде. ну-ну
вы не умеете вести дискуссии, излагать свои мысли и обсуждать с вами что-либо попросту бесполезно. «чукча не читатель — чукча писатель» это как раз про вас
хорошо, вопрос поставлю по другому — в приведеном мною сценарии (если вы не используете внешние ключи) вы вообще не будите проверять не оставил ли контрагент следа у вас в документации перед удалением его из таблицы?
если будите — то да вы сможете ускорить его удаление без внешних ключей за счет того что будите проверять не по всем завязанным таблицам, а лишь только проверите условно критичные таблицы которых может быть в разы меньше чем общее число ссылающихся таблиц. но всегда есть вероятность что какую-то важную табличку вы забыли добавить в проверку и как результат можете получить проблемы которые я описал выше.
если не будите проверять
вообще чаще всего таблицы на которые ссылается множество (ну в моем понимании «множество» это от 50 и больше, но это субъективно) таблиц — это различного рода таблички-словари. смысла удалять из них что либо как правило нет — т.к. придется много чего из дргих таблиц паравозом удалить.
из моего опыта обычно в сценариях с подобными таблицами записи не удаляются из таких табличек, а помечаются как неактивные — таким образом приложение скрывает таких «удаленных» из различных форм поиска. у нас как-то была таблица на которую ссылалось более сотни других внешними ключами и ни у кого и в мыслях не было эти ключи удалять или отключать.
кароче, второй пункт слишком категоричный и потому фтопку.
аффтор вообще не понимает как работает журнал транзакций, иначе такой ереси не написал бы.
запись в журнал транзакций всегда последовательная и от модели восстановления не зависит!
почитайте лучше оф доку по тому как устроен журнал транзакций, а не аффтора тынц на BOL
так как любая (почти) тразакция SQL Server соответствует ACID — это значит что сиквел использует механизм упреждающей записи в журнал транзакций. Этим он гарантирует свойство Durability — в случае сбоя в ходе процесса recovery сиквел из журнала транзакций накатит те транзакции которые успели закомитить, но которые из грязных страниц чекпоинт не успел сбросить на диск в файлы данных. поэтому нагрузка на журнал транзакции большая даже если режим восстановления Simple.
насчет моей оговорки «почти» — это относится к фиче 2014 delay durability. там така транзакция может не сразу записаться из logbuffer на диск — поэтому есть небольшой шанс что в случае сбоя мы потеряем данные по закомиченой транзакции
ну и это ересь и отсутствие понимания того как SQL Server управляет памятью
Также слишком большие объемы ОЗУ, которые предоставляются СУБД, приведут к тому, что последний заполнит всю память неактуальными планами запросов.
но как по мне, то лучшее что выходило из фильмов-сериалов про космос за последние 2-3 года — это Expanse
тут не ошибка случаем, может dplyr?
хотя честно говоря давно на R ничего не делал, то может отстал от жизни :)
когда появится — тогда в серьез задумаюсь над подпиской на таком ресурсе, а пока — пиратствуем
рискну предположить (хотя случаи могут быть разными) — все это размазывание было проведено в ходе N-го количества оптимизаций со стороны базы данных. Дело в том, что я многократно наблюдал как при написании логики в базе данных пытались использовать часть принципов ООП — оно все хорошо, красиво, удобно, проще поддерживать… НО, рано или позно приходят они… тормоза…
То ли это какой-то отчет использующий очень навороченую вьюху на все случаи жизни, в которой есть все что нужно и не нужно париться и особо мудрить. Или же это какая-то аггрегация которая использует функции для каких-то вычислений, в которые упрятанна с глаз долой забористая логика. И все, приехали, вариант один — разворачивать функции-вьюхи, выкидывать все ненужное, а все нужное писать так что бы было максимально быстро. вот после таких оптимизаций логика реализованая в БД может быть весьма тяжело читаемой.
Впрочем, причины могут быть и более тривиальные — в целях экономии времени в процедуру\функцию\триггер вставляют if else с нужным кодом, вместо того что бы переписать процедуру под новые требования. И со временем почти вся процедура слеплена из таких кусков, и без вдумчивого дебага уже непонять что там происходит. Но почему такое происходит не загадка — лень и дедлайны, на то что бы сделать по нормальному, а потом еще и провести хорошее тестирование может потребоваться слишком много времени. Справделивости ради стоит сказать что такое характерно и для ООПшных языков программирования.
В общем, возвращаясь к исходной точке — для БД либо шашечки, либо ехать (либо принципы ООП, либо скорость выполнения)
З.Ы. это моя ИМХА за 13 лет собраная на своем и опыте коллег
ну и еще нанимают ДБА или SQL разработчика, потому что <подставьте язык сами> разрабочики плохо знают тонкости используемой на проекте СУБД, а бывает что и вовсе разучились SQL запросы писать.
Так что учитывать интересы базы рано или поздно придется, от этого никуда не уйти, но тут важно найти разумный компромис.
тоже питаюсь как попало — обычно не завтракаю, уже на работе чего-то к утренему чаюберу, ужин у меня вобще с 20 до 22.
правда я много ем сезонных (или не очень сезонных) фруктов.
из спорта я для себя 4 года назад выбрал фехтование — качалки для меня слишком унылы, груповые виды спорта тоже не для меня. в прицнипе удалось поставить себя на регулярные занятия, хотя иногда все же бывают простои в 1-2 месяца, но стараюсь этого недопускать — на результатах сильно сказывается.
а в таких случаях у них наверняка есть контракт с МС на расширеную поддержку для тех продуктов, для которых у МС уже закончился срок поддержки.
так что я думаю еще спокойно себе не один год смогут сидеть на вин 7\8 пока соответствующий софт под 10 винду не допилят
что-то загнули насчет шести недель, но как минимум на две недели заряда хватает
но вообще да, мне тоже обидно что свернули, я мобильной вин8.1 был очень даже доволен.
за windows mobile конечно обидно. версия 8.1 вполне себе годная, я лично доволен был — но у меня не завышеные потребности, все что мне нужно в ней было. а с мобильной 10-й фейл конечно полнейший получился, поэтому не удивительно что решили свернуть.
установленые левые корневые сертификаты лишь дают возможность выдавать левые сайты за довереные, но не дают возможность например читать мой трафик с gmail? я правильно все понимаю или чего-то не понял из статьи?
а в ответ — перевод темы на индексы и очевидные рассказы что все нужно проверять на тестовом стенде. ну-ну
вы не умеете вести дискуссии, излагать свои мысли и обсуждать с вами что-либо попросту бесполезно. «чукча не читатель — чукча писатель» это как раз про вас
ну поделитесь своим опытом и тем что же неверного вы в моих объяснениях вы там нашли?
и если вы действительно читали БОЛ — почему же не ответили на вопрос DonAlPAtino, а съехали? в приведеной мной ссылке ответ на его вопрос есть
если будите — то да вы сможете ускорить его удаление без внешних ключей за счет того что будите проверять не по всем завязанным таблицам, а лишь только проверите условно критичные таблицы которых может быть в разы меньше чем общее число ссылающихся таблиц. но всегда есть вероятность что какую-то важную табличку вы забыли добавить в проверку и как результат можете получить проблемы которые я описал выше.
если не будите проверять
вообще чаще всего таблицы на которые ссылается множество (ну в моем понимании «множество» это от 50 и больше, но это субъективно) таблиц — это различного рода таблички-словари. смысла удалять из них что либо как правило нет — т.к. придется много чего из дргих таблиц паравозом удалить.
из моего опыта обычно в сценариях с подобными таблицами записи не удаляются из таких табличек, а помечаются как неактивные — таким образом приложение скрывает таких «удаленных» из различных форм поиска. у нас как-то была таблица на которую ссылалось более сотни других внешними ключами и ни у кого и в мыслях не было эти ключи удалять или отключать.
кароче, второй пункт слишком категоричный и потому фтопку.
запись в журнал транзакций всегда последовательная и от модели восстановления не зависит!
почитайте лучше оф доку по тому как устроен журнал транзакций, а не аффтора тынц на BOL
так как любая (почти) тразакция SQL Server соответствует ACID — это значит что сиквел использует механизм упреждающей записи в журнал транзакций. Этим он гарантирует свойство Durability — в случае сбоя в ходе процесса recovery сиквел из журнала транзакций накатит те транзакции которые успели закомитить, но которые из грязных страниц чекпоинт не успел сбросить на диск в файлы данных. поэтому нагрузка на журнал транзакции большая даже если режим восстановления Simple.
насчет моей оговорки «почти» — это относится к фиче 2014 delay durability. там така транзакция может не сразу записаться из logbuffer на диск — поэтому есть небольшой шанс что в случае сбоя мы потеряем данные по закомиченой транзакции
ну и это ересь и отсутствие понимания того как SQL Server управляет памятью