Для сотрудника должно быть понятно, что сообщив новость, он точно сохранит работу, это и называется безопасность в команде. Создание такой атмосферы — задача руководителя, и он может продемонстрировать эту безопасность как раз реакцией на плохие новости.
Все мы люди и, к сожалению, все ошибаемся.
Если это новая среда, в которой вы не знаете как себя вести, попробуйте спросить совета у коллег — что было и как. Как вариант, попробуйте принести плохую новость, например, что срок сдвигается на пару дней — или вы оракул и очень хорошо определяете сроки, или у вас бывали такие ситуации. Посмотрите на реакцию, обычно этого достаточно, чтобы предугадать, что будет дальше.
Про hint ы на то как делать соединение таблиц, было пару случаев где оптимизация свелась просто к убиранию хинта и все стало работать в разы быстрее. Все-таки прибитое гвоздями надо периодически мониторить и смотреть как оно там, а так как кода много, про существующие в коде хинты часто забывают. Видимо хинт прожил в том месте, откуда я его убрала, довольно долго и возможно пережил переезд на новую версию SQL Server.
Спасибо!
В вашей иллюстрации получается лучше показать разницу между хэш функцией и значениями в таблице. И тоже очень интересный момент, мне кажется, который я не проговорила — за счет чего получается ускорение по сравнению с Nested loops.
Про мерж — отличная иллюстрация про радугу, так как в мерж они уже отсортированы благодаря индексам, но в примере с баночками это не очень наглядно.
Буду пользоваться с вашего позволения улучшенными примерами.
Э-эх, это больной вопрос. Пока ничего не делаем, у нас SSD диски.
К сожалению пока мы не придумали пляску с бубном, чтобы неафектить прод и делать дефрагментацию. С Rebuild With online=on все равно есть проблемы на нагрузочных тестах, в теории идельно было бы использовать reorg так как сохраняется прогресс, который мы бы запускали в часы низкой нагрузки и часов 6 с субботы на воскресенье, с прерыванием после того как время истекло, даже если процесс еще идет.
Про съезжающие статистики — есть джоб, который запускает обновление статистик по большим таблицам, но там тоже не все идеально.
Да есть реплики, мастер и read-only в Availability Group. Изменения я могу применить только на master реплику, то есть сделать изменения схемы для read реплики и потом failover на нее не получится.
Для read с read-only реплики эта таблица не использовалась, так как к сожалению в SQL Server 2012 были нюансы с выборками с read-only реплик по производительности.
В этом есть своя соль, к сожалению всегда проблема в балансе между ресурсами команды на рефакторинг и добавлении новых фич, чтобы успеть за рынком, пока баланс сильно смещен в сторону новых фич, и рефакторинг происходит в момент, когда «уже дальше так нельзя». Некоторый функционал переведен на решения не через MS SQL.
В проекте бизнес логика и в БД тоже, это мне кажется довольно холиварный вопрос, на который у меня нет ответа, потому что так сложилось, что все проекты, в которых я работала имели много бизнес логики в бД, а хотелось бы помимо теории, попробовать руками.
Теперь по пунктам:
про управление релизами всегда есть код для релиза в БД и приложения, конечно ни о каком полном стопе не может быть и речи, процедуры всегда делаются с обратной совместимостью и сначала накатывает код для БД, потом обновляется приложение. Код для релиза базы готовится с помощью специального ПО, которое помогает сформировать скрипты для деплоя и отката изменений в случае чего, всегда делается версия для отката изменений и пишется иснтрукция для ДБА, если откат много ступенчатый и сложный, но обычно нужно просто последовательно применить файлы с sql кодом на базу.
это sql server и ненужно вызывать рекопиляцию, как кажется надо делать в Oracle, server сам рекомпилирует процедуры, ситуаций, когда этого не случалось или рекомпиляция почему то ломалась не было.
про eval — простите нужно больше деталей, не очень понимаю о чем речь, писала на javascript довольно давно, но возможно это решается походом в кэш (он есть)
сложность шардирования — да, это сложно и тут БД шардированы и это был целый проект по шардингу, я его не застала и пришла в команду уже после
тоже про alter table — в теории да, по факту даже когда таблица меняется и она используется во многих процедурах это не вызывает проблему на сервере (спасибо разработчикам СУБД)
да тесты — это головная боль, в проекте нет отдельных тестов для БД, есть тесты для приложения, если в БД есть отдельный функционал, обычно там же добавляют тесты для его проверки через приложение.
Совсем не обязательно этот подход является оптимальным, ситуация as is, и подходы к ее решению скованы пока тем, что не переписываем все заново, хотя возможно к этому и придут.
У нас были SQL Server консультанты, но почему то ни мы ни консультанты не смотрели в ту сторону, хотя возможно стоит сделать проект и посмотреть насколько сложно будет перенести, и насколько будет выигрыш — так как нагрузочные тесты можно запусктаь на специальной среде, то это вполне можно проверить, осталось взвесить за и против, эта таблица вполне хороший кандидат.
Приложение фоновое и оно просто постучится к БД еще раз с тем же запросом, и уже попадет на рабочую БД. Получается мы перестаем обслуживать запросы к одной таблице, но зато остальные запросы не подвергаются влиянию, во время применения индекса.
По сути мы немного избавляем сервер от необходимости выстраивать очередь доступа к этой таблице на время применения индекса, что экономит его ресурсы и он спокойно обрабатывает другие запросы и делает наш индекс.
Vladnev и K010mb0 уже хорошо ответили на вопрос, это и правда кровавый enterprise про большую нагрузку и с оптимизированными запросами с хранимыми процедурами работает хорошо (кэш планов процедур и прочие плюшки).
Кроме того хотя и были agile команды, все равно ест люди, которые хорошо видят, что может вызвать проблемы на базе, а другие что в коде приложения, получается что можно разделять ревью, что и делали, даже проект на БД и приложение разные и это позволяет быстрее проходить ревью.
Довольно часто летаю и очень удивлена, что Внуково — аэропорт года, мне он удобен, потому что я к нему довольно близко работаю.
То что очень не нравится:
очереди на выходе из аэроэкспресса — иногда можно простоять минут 30 на выходе + досмотре
очереди на выход в зону досмотра (как раз упомянутывае выше девушки, которые ставят штампик в билете, пару раз попадала так что эта очередь заняла до 40 минут, и пришлось лезть без очереди, так как уже заканчивалась посадка
неразбериха на подъезде в зону для встречающих в аэропорту и на эстакаде, несмотря на постоянные предупреждения службы аэропорта внутри стоит куча таксистов с поднятыми багажниками, чтобы не было видно номеров и создают пробку, иногда можно простоять в пробке на эстакаде 20 минут и прождать такси, которое уже въехало на территорию аэропорта минут 30, что в мороз очень не радует
В общем и целом по моему опыту и Домодедово и Шереметьево не страдают таким количество очередей.
я частично не соглашусь, конечно в первую очередь должна быть ответственность за то, чтобы все работало, в смысле выбранные технологии обеспечивали выполнение поставленных задач, но коммуникации тоже очень важны. При этом коммуницировать может не сам архитектор на всех уровнях, он может это частично отдать аналитику или developer advocate, но сам процесс должен быть. Может быть я немного идеализирую, но я считаю, что часто как раз из-за плохо проведенной коммуникации проект не взлетает. Решение не только должно быть принято, но и донесено до всех участвующих почему именно такое решение принято. Например, если разработчики против или не понимают почему тут должна быть вот такая технология — важно проработать этот момент — показать чем руководствовались, какие альтернативы рассматривали. ИТ — область высокоинтеллектуальных сотрудников, и с ними не получится работать как на стройке — инженер сказал как делать, а вы молчите и делайте. На мой взгляд вот такое «спускание решений сверху» и не приятие и не понимание их командой часто причина того, что внутренее сопротивление очень сильно замедляет реализацию проекта.
Судя по Wikipedia нет, ваш пример как раз характеризует об архитектурных проблемах проекта, которые возможно имели место быть и при строительстве этого замка. Шамбор мне всегда казался несколько сумасшедшим, но красивым. Этаким строительным воплощением проекта, с кучей костылей, которые к сожалению не выглядят столь прекрасно как этот замок.
Спасибо, хочется больше подробностей!
Было бы здорово как это работает технически и сам процесс, как собирают данные какие витрины делать, кто решает, что это нужно делать.
И было бы здорово один-два кейса на примере, может быть рассказывали.
Еще интересно как учили далеких от программирования пользователей SQL.
Спасибо за статью, очень нужна такая информация об опасности этого выведенного борщевика, муж — офтальмолог и он рассказывает, что к сожалению случаи слепоты среди детей, которые решили поиграть с телескопом встречаются до сих пор, так что борьба с неведением очень важная штука.
Спасибо за статью!
У Франкла целая книга есть «Человек в поисках смысла», к сожалению некоторым корпорациям очень сложно донести смысл на все уровни сотрудников. Он теряется где-то в пути и это печально.
Последний абзац «Сотрудники работают усерднее, увольняются чаще, притягиваются к поддерживающим рабочим культурам, помогающим им расти.» Наверное не чаще, а реже.
Скорее всего описались.
Спасибо, интересно и во многом совпадает с моим опытом работы в команде. позабавил пункт из смертных грехов про «не закапываемся в очень редкие кейсы» по моим наблюдениям такое поведение больше свойство личности и иногда полезное, а иногда вредное и тормозящее работу. Как это лечите в команде? или озвученной договоренности достаточно?
Автор Dr Rick Wolfe первую лазерную коррекцию в Австралии сделал в 1991, в профессии с 1984.
Мне делали коррекцию еще LASIKом — небольшая близорукость + астигматизм. Один глаз видел 100 %, а один такой с -1 — неудобно.
Я довольна, так как теперь оба глаза 100%
Какое то время сделала перерыв в спорте (где-то 1 — 1,5 месяца). Катаюсь на лыжах, на вейке. На вейке падения были об воду, но с клапаном (лоскутом) все ок. Глаза правда стараюсь не тереть: ))
Все мы люди и, к сожалению, все ошибаемся.
Если это новая среда, в которой вы не знаете как себя вести, попробуйте спросить совета у коллег — что было и как. Как вариант, попробуйте принести плохую новость, например, что срок сдвигается на пару дней — или вы оракул и очень хорошо определяете сроки, или у вас бывали такие ситуации. Посмотрите на реакцию, обычно этого достаточно, чтобы предугадать, что будет дальше.
В вашей иллюстрации получается лучше показать разницу между хэш функцией и значениями в таблице. И тоже очень интересный момент, мне кажется, который я не проговорила — за счет чего получается ускорение по сравнению с Nested loops.
Про мерж — отличная иллюстрация про радугу, так как в мерж они уже отсортированы благодаря индексам, но в примере с баночками это не очень наглядно.
Буду пользоваться с вашего позволения улучшенными примерами.
К сожалению пока мы не придумали пляску с бубном, чтобы неафектить прод и делать дефрагментацию. С Rebuild With online=on все равно есть проблемы на нагрузочных тестах, в теории идельно было бы использовать reorg так как сохраняется прогресс, который мы бы запускали в часы низкой нагрузки и часов 6 с субботы на воскресенье, с прерыванием после того как время истекло, даже если процесс еще идет.
Про съезжающие статистики — есть джоб, который запускает обновление статистик по большим таблицам, но там тоже не все идеально.
Для read с read-only реплики эта таблица не использовалась, так как к сожалению в SQL Server 2012 были нюансы с выборками с read-only реплик по производительности.
Теперь по пунктам:
Совсем не обязательно этот подход является оптимальным, ситуация as is, и подходы к ее решению скованы пока тем, что не переписываем все заново, хотя возможно к этому и придут.
По сути мы немного избавляем сервер от необходимости выстраивать очередь доступа к этой таблице на время применения индекса, что экономит его ресурсы и он спокойно обрабатывает другие запросы и делает наш индекс.
Кроме того хотя и были agile команды, все равно ест люди, которые хорошо видят, что может вызвать проблемы на базе, а другие что в коде приложения, получается что можно разделять ревью, что и делали, даже проект на БД и приложение разные и это позволяет быстрее проходить ревью.
То что очень не нравится:
В общем и целом по моему опыту и Домодедово и Шереметьево не страдают таким количество очередей.
немного напомнило нетленку про Повелитель-Штурмовик
Было бы здорово как это работает технически и сам процесс, как собирают данные какие витрины делать, кто решает, что это нужно делать.
И было бы здорово один-два кейса на примере, может быть рассказывали.
Еще интересно как учили далеких от программирования пользователей SQL.
У Франкла целая книга есть «Человек в поисках смысла», к сожалению некоторым корпорациям очень сложно донести смысл на все уровни сотрудников. Он теряется где-то в пути и это печально.
Последний абзац «Сотрудники работают усерднее, увольняются чаще, притягиваются к поддерживающим рабочим культурам, помогающим им расти.» Наверное не чаще, а реже.
Скорее всего описались.
Немного альтернативного мнения про SMILE
https://www.vistaeyes.com.au/laser-eye-surgery-smile-not-smile-top-10-things-need-know-smile/
Автор Dr Rick Wolfe первую лазерную коррекцию в Австралии сделал в 1991, в профессии с 1984.
Мне делали коррекцию еще LASIKом — небольшая близорукость + астигматизм. Один глаз видел 100 %, а один такой с -1 — неудобно.
Я довольна, так как теперь оба глаза 100%
Какое то время сделала перерыв в спорте (где-то 1 — 1,5 месяца). Катаюсь на лыжах, на вейке. На вейке падения были об воду, но с клапаном (лоскутом) все ок. Глаза правда стараюсь не тереть: ))