В целом хорошие советы но большинство их было актуально во времена 9 оракла. Особенно не согласен с HINT. Ми их интенсивно убирали с проекта при переходе на 10 или 11 оракл. В 13 от них и следа не осталось. Учитивая что для одного и того ж запроса оракл может делать разние планы в зависимости от значений входных параметров. А использование MV как правило приносит больше проблем чем пользы. И рекомендовать использовать его людям, которие еще не умеют читать планы - думаю неправильно. Ну и ни слова о Result Cache.
Ностальгия. Мой путь sl45=>(el71(зима)\e71(лето) Причем sl55 и sl65 пропустил из за отсуствия SD и соответственно полноценного MP3 плеера. Мультисимпач самий полезний для меня. Только во времена android 4.4 Xiaomi Redmi 2 стал основним телефоном.
Но вот проблема в том что война то затягивается. И не завершится еще долго. И нужно покупать/создавать новые танки. А от ето уже сегоднишние зароботки.
Не уменьшая значения и важности in memory баз можно писать и без маркетинговой фигни про и 5-10 минут. А по факту при правильной архитектуре и разделении на OLTP и DW аналитические отчёты за любой период — до 10с. И самая кровавая банковская классическая база неожиданно умеет и колоночное хранение и in memory и еще бог знает что еще. А прикрути сюда OLAP и вы покрыли все аналитические запроси.
Вот и главное. Для меня даные в БД должны быть достоверными, а не с формолировкой
минимально-достаточной непротиворечивости данных
. Да и выбор в етом 1С мне не дал.
По поводу FK — они берут на себе огромную часть БЛ. Имеют оверхед в виде необходимости индексов.
Ну и поверхносное гугление статью не дало.
Ну а поддержка многих баз — ето лиш говорит о том что 1С нормально не поддерживае ни одну.
А и да «ы» у меня нет. пользуюсь буфером обмена :)
И какие минуса (отсуствие битих ссилок)?
А с партиции 1с не поддерживает, ви их создаете на уровне БД, что кстати запрещено лицензионним соглашением. Ну и они чудно пропадут при перестроении.
В 1С качественная изоляция прикладного кода от слоя работы с БД. Там нельзя типизировать таблицы на низком уровне и косяки малокомпетентных джуниоров на уровне БД там невозможны.
Так ето и беда 1С для средних и крупных баз.
Использование БД как хранилища таблиц, не учитивая возможности БД катие как партиции форенкеи, тригери и тд. Сколько костилей из за етого.
Работа с БД для меня одина из наиболее слабых сторон в 1С
Это работает только при массовом клепании Однотипных Форм (тм).
Уж точно нет.
Бизнес не знает, как решить проблему.
Так значит и нет задач.
Тимлид не видит (почему, кстати, тимлид?)
Согласен не тимлид. (но назовите как хотите архитектор+тимлид+ начальник оттела разработки, суть то не меняет )
как интегрировать в систему.
Ну уж если он не видит то усе… смисла в отделе нет. И тут уже ничто не поможет ни скрам ни Аджайл ни Менеджер.
Оценки, как всегда, ошибаются в 2,5 раза
Та ладно ви точноее даете оценку? если да то сколько занимает процес оценки? Или по скраму сбросились фантиками и большинство оценило?
Так от, если процес оценки занимает больше 1 часа команды или емеет допуск боле 50% есть ли смисл?
Или вообще никто подобных задач не делал,
И как в етом поможет Аджайл?
конечный результат мало кто себе переставляет
Если так, то какой смисл начинать?
И как в етом поможет Аджайл?
Разработчики не хотят делать навязанные им задачи, а хотят развиваться
то есть отсутствие каноничного Аджайл подразумевает по умолчанию бардак?
Интересная мысль.
Джуны боятся сказать о проблеме и тянут до последнего
Во время работы, тимлид знает кого нужно спросить не нужна ли помощь, кого то нужно подстегнуть и тд.
Результат всегда оказывается не тем, что все себе переставляли.
Как я уже писал НЕЛЬЗЯ Начинать проек не представляя конечного результата. И ето железное правило.
Как по мне, эти все методики нужны для управления не командами, а случайными программистами, которих собрали для проекта.
Но если у вас команда — методики только мешают.
Объясню.
Например Бизнес непосредственно ставит задачу тимлиду или ищут решение проблеме (он разбирается в БП компании не хуже бизнеса ). Тимлид видит как интегрировать задачу в существующий продукт. Составляет план, и архитектуру решения.
Представляет задачу и архитектуру решения команде.
Далее команда критикует решение, и они обсуждают недочёты и альтернативные возможности. Пока не достигнут решения. При необходимости анализируются альтернатива и после етого встречаются повторно.
Дальше задача разбивается на более мелкие подзадачи. И при необходимости обсуждаются их детали. Важно, что б все в команде понимали что ми делаем, а не писали функцию или клас.
Дальше тимлид раздает подзадачи с учетом сильных и слабых сторон подчинённых, учитывая важность других текущих задач.(Не знаю как у вас, но редко бывает одна задача в работе.)
Во время работы, тимлид знает кого нужно спросить не нужна ли помощь, кого то нужно подстегнуть и тд. По ходу продвижения работ меняет при необходимости как подзадачи так и исполнителей. И да он тоже в задаче.
Если проект большой, можно раз в недельку собраться, но как правило все в одном месте и перекликнутся, или попросить о помощи куда ефективнее.
И да команда это не только работа, а и вместе дни рождения, футбол, пикники, поездки по грибы,…
И даже если в пылу разговора кто-то кого-то послал то это означает что нужно разойтись и через полчаса обсудить повторно.
Хотя я согласен, что в больших IT компаниях с большим числом заказчиков и продуктов, наверное по другому не работает.
Очень интересно как вы ети методики натянете на разработку ПО?
Реально интересно. Я реально видел ефект в произвотстве, но вразработке ПО?
Если команда адекватная, единственный путь сделать продукт — писать код, а не следовать учениям.
Уважаемые читатели! Как вы относитесь к приложениям, основанным на Electron?
Skype,… Ну і как можно относится к приложениям, которие лагают на топовом железе?
Да у нас проблема с мультиплатформеним GUI, но костили в виде Electron і других не сильно то помогают.
Наверное нужно создавать что на подобиии NET Только для GUI (GUI STANDART) на основании какойто разметки. И главное добится что б оно работало на всех платформах.
Вы наверное никогда не работали с power серверами, иначе никогда б не написали
Как числодробилка проиграет GPU, а как сервер — интелю.
Ибо Power по производительности ядра не проигрывает интелу. А при 100% загрузке всех ядер процесора, например нагрузка вызвана БД — вы сразу поймете в чем разница POWER и INTEL Сервера на Power ето другой сегмент и другая производительнось и серверам на Xeon ещо расти и расти. Если ето возможно архетектурно.
Пользовательские блокировки.
Последнее средство — вручную установить исключительную блокировку или на все нужные строки (SELECT FOR UPDATE), или вообще на всю таблицу (LOCK TABLE). Это всегда работает, но сводит на нет преимущества многоверсионности: вместо одновременного выполнения часть операций будет выполняться последовательно.
Не совсем согласен.
Ето минимальное зло. При правильном SELECT мы блокируем только нужние записи.(для примера одного клиента) И операции по другим клиентам проходят паралельно. Но следует учитивать что для всех изменений в даной таблице нужно предварительно использовать
SELECT FOR UPDATE в идеале использовать одну сторедж процедуру.
P.S. Хорошая статтья, На жаль многие разработчики не хотят вникать в такие детали БД.
Нет, единственное что Тесла сформировала — хайп вокруг электромобилей
Нет Тесла(Маск) сделала намного больше — уже 2025-2030 годах в европе в городах воздух станет лутше. Мне всеравно заработают акционеры теслы или нет. Но ето крутое достижение. Как переход в городах з угля на газ, как центральная канализация и водоснабжение.
В оракле можно так: alter index indexname unusable; Но ведь оракл стоит слишком дорого :)
В целом хорошие советы но большинство их было актуально во времена 9 оракла. Особенно не согласен с HINT. Ми их интенсивно убирали с проекта при переходе на 10 или 11 оракл. В 13 от них и следа не осталось. Учитивая что для одного и того ж запроса оракл может делать разние планы в зависимости от значений входных параметров. А использование MV как правило приносит больше проблем чем пользы. И рекомендовать использовать его людям, которие еще не умеют читать планы - думаю неправильно. Ну и ни слова о Result Cache.
Ностальгия. Мой путь sl45=>(el71(зима)\e71(лето) Причем sl55 и sl65 пропустил из за отсуствия SD и соответственно полноценного MP3 плеера. Мультисимпач самий полезний для меня. Только во времена android 4.4 Xiaomi Redmi 2 стал основним телефоном.
Но вот проблема в том что война то затягивается. И не завершится еще долго. И нужно покупать/создавать новые танки. А от ето уже сегоднишние зароботки.
По поводу FK — они берут на себе огромную часть БЛ. Имеют оверхед в виде необходимости индексов.
Ну и поверхносное гугление статью не дало.
Ну а поддержка многих баз — ето лиш говорит о том что 1С нормально не поддерживае ни одну.
А и да «ы» у меня нет. пользуюсь буфером обмена :)
А с партиции 1с не поддерживает, ви их создаете на уровне БД, что кстати запрещено лицензионним соглашением. Ну и они чудно пропадут при перестроении.
Так ето и беда 1С для средних и крупных баз.
Использование БД как хранилища таблиц, не учитивая возможности БД катие как партиции форенкеи, тригери и тд. Сколько костилей из за етого.
Работа с БД для меня одина из наиболее слабых сторон в 1С
Мне про ненастоящего как то больше зашло.
Так значит и нет задач.
Согласен не тимлид. (но назовите как хотите архитектор+тимлид+ начальник оттела разработки, суть то не меняет )
Ну уж если он не видит то усе… смисла в отделе нет. И тут уже ничто не поможет ни скрам ни Аджайл ни Менеджер.
Та ладно ви точноее даете оценку? если да то сколько занимает процес оценки? Или по скраму сбросились фантиками и большинство оценило?
Так от, если процес оценки занимает больше 1 часа команды или емеет допуск боле 50% есть ли смисл?
И как в етом поможет Аджайл?
Если так, то какой смисл начинать?
И как в етом поможет Аджайл?
то есть отсутствие каноничного Аджайл подразумевает по умолчанию бардак?
Интересная мысль.
Как я уже писал НЕЛЬЗЯ Начинать проек не представляя конечного результата. И ето железное правило.
Ну да есть Правда, Лож и Статистика. :)
Но если у вас команда — методики только мешают.
Объясню.
Например Бизнес непосредственно ставит задачу тимлиду или ищут решение проблеме (он разбирается в БП компании не хуже бизнеса ). Тимлид видит как интегрировать задачу в существующий продукт. Составляет план, и архитектуру решения.
Представляет задачу и архитектуру решения команде.
Далее команда критикует решение, и они обсуждают недочёты и альтернативные возможности. Пока не достигнут решения. При необходимости анализируются альтернатива и после етого встречаются повторно.
Дальше задача разбивается на более мелкие подзадачи. И при необходимости обсуждаются их детали. Важно, что б все в команде понимали что ми делаем, а не писали функцию или клас.
Дальше тимлид раздает подзадачи с учетом сильных и слабых сторон подчинённых, учитывая важность других текущих задач.(Не знаю как у вас, но редко бывает одна задача в работе.)
Во время работы, тимлид знает кого нужно спросить не нужна ли помощь, кого то нужно подстегнуть и тд. По ходу продвижения работ меняет при необходимости как подзадачи так и исполнителей. И да он тоже в задаче.
Если проект большой, можно раз в недельку собраться, но как правило все в одном месте и перекликнутся, или попросить о помощи куда ефективнее.
И да команда это не только работа, а и вместе дни рождения, футбол, пикники, поездки по грибы,…
И даже если в пылу разговора кто-то кого-то послал то это означает что нужно разойтись и через полчаса обсудить повторно.
Хотя я согласен, что в больших IT компаниях с большим числом заказчиков и продуктов, наверное по другому не работает.
Очень интересно как вы ети методики натянете на разработку ПО?
Реально интересно. Я реально видел ефект в произвотстве, но вразработке ПО?
Если команда адекватная, единственный путь сделать продукт — писать код, а не следовать учениям.
Хотя идеи очень интересные. Надеюсь он взлетит. Но пока…
Skype,… Ну і как можно относится к приложениям, которие лагают на топовом железе?
Да у нас проблема с мультиплатформеним GUI, но костили в виде Electron і других не сильно то помогают.
Наверное нужно создавать что на подобиии NET Только для GUI (GUI STANDART) на основании какойто разметки. И главное добится что б оно работало на всех платформах.
Ведь дание точно есть в базе.
А все свелось к одной таблице и двумя графиками.
Ибо Power по производительности ядра не проигрывает интелу. А при 100% загрузке всех ядер процесора, например нагрузка вызвана БД — вы сразу поймете в чем разница POWER и INTEL Сервера на Power ето другой сегмент и другая производительнось и серверам на Xeon ещо расти и расти. Если ето возможно архетектурно.
Не совсем согласен.
Ето минимальное зло. При правильном SELECT мы блокируем только нужние записи.(для примера одного клиента) И операции по другим клиентам проходят паралельно. Но следует учитивать что для всех изменений в даной таблице нужно предварительно использовать
SELECT FOR UPDATE в идеале использовать одну сторедж процедуру.
P.S. Хорошая статтья, На жаль многие разработчики не хотят вникать в такие детали БД.
Нет Тесла(Маск) сделала намного больше — уже 2025-2030 годах в европе в городах воздух станет лутше. Мне всеравно заработают акционеры теслы или нет. Но ето крутое достижение. Как переход в городах з угля на газ, как центральная канализация и водоснабжение.