Pull to refresh
-17
-0.1
Олег Рутковський @OlehR

Пользователь

Send message

В оракле можно так: 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 стал основним телефоном.

Но вот проблема в том что война то затягивается. И не завершится еще долго. И нужно покупать/создавать новые танки. А от ето уже сегоднишние зароботки.

Ето решается пультом с програмируемими кнопками под TV, или поддержкой hdmi-cec телевизором.
Не уменьшая значения и важности in memory баз можно писать и без маркетинговой фигни про и 5-10 минут. А по факту при правильной архитектуре и разделении на OLTP и DW аналитические отчёты за любой период — до 10с. И самая кровавая банковская классическая база неожиданно умеет и колоночное хранение и in memory и еще бог знает что еще. А прикрути сюда OLAP и вы покрыли все аналитические запроси.
Вот и главное. Для меня даные в БД должны быть достоверными, а не с формолировкой
минимально-достаточной непротиворечивости данных
. Да и выбор в етом 1С мне не дал.
По поводу FK — они берут на себе огромную часть БЛ. Имеют оверхед в виде необходимости индексов.
Ну и поверхносное гугление статью не дало.
Ну а поддержка многих баз — ето лиш говорит о том что 1С нормально не поддерживае ни одну.
А и да «ы» у меня нет. пользуюсь буфером обмена :)
И какие минуса (отсуствие битих ссилок)?
А с партиции 1с не поддерживает, ви их создаете на уровне БД, что кстати запрещено лицензионним соглашением. Ну и они чудно пропадут при перестроении.
В 1С качественная изоляция прикладного кода от слоя работы с БД. Там нельзя типизировать таблицы на низком уровне и косяки малокомпетентных джуниоров на уровне БД там невозможны.

Так ето и беда 1С для средних и крупных баз.
Использование БД как хранилища таблиц, не учитивая возможности БД катие как партиции форенкеи, тригери и тд. Сколько костилей из за етого.
Работа с БД для меня одина из наиболее слабых сторон в 1С
Неубедительно.
Мне про ненастоящего как то больше зашло.
Это работает только при массовом клепании Однотипных Форм (тм).
Уж точно нет.
Бизнес не знает, как решить проблему.
Так значит и нет задач.
Тимлид не видит (почему, кстати, тимлид?)
Согласен не тимлид. (но назовите как хотите архитектор+тимлид+ начальник оттела разработки, суть то не меняет )
как интегрировать в систему.

Ну уж если он не видит то усе… смисла в отделе нет. И тут уже ничто не поможет ни скрам ни Аджайл ни Менеджер.
Оценки, как всегда, ошибаются в 2,5 раза

Та ладно ви точноее даете оценку? если да то сколько занимает процес оценки? Или по скраму сбросились фантиками и большинство оценило?
Так от, если процес оценки занимает больше 1 часа команды или емеет допуск боле 50% есть ли смисл?
Или вообще никто подобных задач не делал,

И как в етом поможет Аджайл?
конечный результат мало кто себе переставляет

Если так, то какой смисл начинать?
И как в етом поможет Аджайл?
Разработчики не хотят делать навязанные им задачи, а хотят развиваться

то есть отсутствие каноничного Аджайл подразумевает по умолчанию бардак?
Интересная мысль.

Джуны боятся сказать о проблеме и тянут до последнего
Во время работы, тимлид знает кого нужно спросить не нужна ли помощь, кого то нужно подстегнуть и тд.

Результат всегда оказывается не тем, что все себе переставляли.
Как я уже писал НЕЛЬЗЯ Начинать проек не представляя конечного результата. И ето железное правило.
на реальных примерах и со статистикой
Ну да есть Правда, Лож и Статистика. :)

Как по мне, эти все методики нужны для управления не командами, а случайными программистами, которих собрали для проекта.
Но если у вас команда — методики только мешают.
Объясню.
Например Бизнес непосредственно ставит задачу тимлиду или ищут решение проблеме (он разбирается в БП компании не хуже бизнеса ). Тимлид видит как интегрировать задачу в существующий продукт. Составляет план, и архитектуру решения.
Представляет задачу и архитектуру решения команде.
Далее команда критикует решение, и они обсуждают недочёты и альтернативные возможности. Пока не достигнут решения. При необходимости анализируются альтернатива и после етого встречаются повторно.
Дальше задача разбивается на более мелкие подзадачи. И при необходимости обсуждаются их детали. Важно, что б все в команде понимали что ми делаем, а не писали функцию или клас.

Дальше тимлид раздает подзадачи с учетом сильных и слабых сторон подчинённых, учитывая важность других текущих задач.(Не знаю как у вас, но редко бывает одна задача в работе.)

Во время работы, тимлид знает кого нужно спросить не нужна ли помощь, кого то нужно подстегнуть и тд. По ходу продвижения работ меняет при необходимости как подзадачи так и исполнителей. И да он тоже в задаче.

Если проект большой, можно раз в недельку собраться, но как правило все в одном месте и перекликнутся, или попросить о помощи куда ефективнее.

И да команда это не только работа, а и вместе дни рождения, футбол, пикники, поездки по грибы,…
И даже если в пылу разговора кто-то кого-то послал то это означает что нужно разойтись и через полчаса обсудить повторно.

Хотя я согласен, что в больших IT компаниях с большим числом заказчиков и продуктов, наверное по другому не работает.

Канбан, 6сигм

Очень интересно как вы ети методики натянете на разработку ПО?
Реально интересно. Я реально видел ефект в произвотстве, но вразработке ПО?
Если команда адекватная, единственный путь сделать продукт — писать код, а не следовать учениям.

Я слежу за етим проектом, Пока он в стадии альфа-бетта.
Хотя идеи очень интересные. Надеюсь он взлетит. Но пока…
Уважаемые читатели! Как вы относитесь к приложениям, основанным на Electron?

Skype,… Ну і как можно относится к приложениям, которие лагают на топовом железе?
Да у нас проблема с мультиплатформеним GUI, но костили в виде Electron і других не сильно то помогают.
Наверное нужно создавать что на подобиии NET Только для GUI (GUI STANDART) на основании какойто разметки. И главное добится что б оно работало на всех платформах.
Мне кажиться что на SQL ету задачу можно решить и попроще, и точно будет не медленнее.
Ведь дание точно есть в базе.
Уж извините но в стати с таким оглавлением ожидаешь увидеть материал с раскрытой темой.
А все свелось к одной таблице и двумя графиками.
Вы наверное никогда не работали с power серверами, иначе никогда б не написали
Как числодробилка проиграет GPU, а как сервер — интелю.

Ибо Power по производительности ядра не проигрывает интелу. А при 100% загрузке всех ядер процесора, например нагрузка вызвана БД — вы сразу поймете в чем разница POWER и INTEL Сервера на Power ето другой сегмент и другая производительнось и серверам на Xeon ещо расти и расти. Если ето возможно архетектурно.
Пользовательские блокировки.
Последнее средство — вручную установить исключительную блокировку или на все нужные строки (SELECT FOR UPDATE), или вообще на всю таблицу (LOCK TABLE). Это всегда работает, но сводит на нет преимущества многоверсионности: вместо одновременного выполнения часть операций будет выполняться последовательно.


Не совсем согласен.
Ето минимальное зло. При правильном SELECT мы блокируем только нужние записи.(для примера одного клиента) И операции по другим клиентам проходят паралельно. Но следует учитивать что для всех изменений в даной таблице нужно предварительно использовать
SELECT FOR UPDATE в идеале использовать одну сторедж процедуру.
P.S. Хорошая статтья, На жаль многие разработчики не хотят вникать в такие детали БД.
Нет, единственное что Тесла сформировала — хайп вокруг электромобилей

Нет Тесла(Маск) сделала намного больше — уже 2025-2030 годах в европе в городах воздух станет лутше. Мне всеравно заработают акционеры теслы или нет. Но ето крутое достижение. Как переход в городах з угля на газ, как центральная канализация и водоснабжение.

Information

Rating
Does not participate
Location
Ужгород, Закарпатская обл., Украина
Date of birth
Registered
Activity