Позвольте подушнить, но вы не правильно понимаете требования:
Масштабируемость - это как раз про увеличение нагрузки, а вы приводите пример про расширение функционала, это уже "Расширяемость" или "Гибкость" или "Устойчивость к изменениям"...
Законодательные и отраслевые требования - эти требования и стандарты напрямую влияют на систему, в том числе из таких требований часто вытекают и функциональные требования, поэтому это более чем обязательная зона ответственности системного аналитика, а не второстепенная, как вы ее пытаетесь представить. Хорошо если бизнес-аналитик сформирует вам их, но если нет, то системный аналитик должен это сделать сам.
Надёжность - пример типа "не более ... в такое-то время..." в 9-ках описывается требование по доступности, обычно оно не включает какие-то плановые простои, например на обслуживание, т.е. речь идет о сбоях, а их нельзя запланировать, поэтому указание промежутка времени здесь выглядит странно. Вы же скорее уже пытаетесь описать SLA.
Зарегистрировались чтобы написать этот комментарий? Ну-ну... Отзывы они такие отзывы... Наверное и продукт то хороший, но вот такие методы продвижения сразу отталкивают.
Не понял про какую не свою работу вы говорите... И не надо никому рассказывать о чужих проблемах... Не продуктивно обхаживать админа который не хочет/не может сделать то что вы от него хотите. Мой сценарий: РП: надо сделать то-то Админ: Мне некогда, у меня другая задача идем к начальнику админа/пишем с копией своего начальника... РП: Мне от вашего админа надо то-то, он занят другим вашим поручением, у вас такие-то обязательства по проекту... Начальник админа либо меняет приоритеты и дает задание админу, либо посылает вас так как его задача действительно важнее, беря ответственность на себя и в любом случае задумываясь в очередной раз о нехватке кадров и получая доп. аргумент для расширения штата. Вы при этом получаете официальный ответ и прикрытую задницу, все в плюсе, если эту ситуацию можно так назвать
Статью следовало бы назвать "как РП прикрыть свою задницу". В описанной вами истории стало жалко админа, он и так 1 и зп у него маленькая и дел у него 100 одновременно, а вы его виноватым пытаетесь сделать. Конечно когда он увидит это (попытки оставить его крайним) он попытается пошевелиться, но это скорее всего будет в ущерб других его дел и он всё равно останется виноватым в другом месте. Реальная проблема в этой истории, то что кто-то не может обеспечить требуемое количество персонала, достойную ЗП, а возможно и квалификацию, но это все связано... Но это конечно не ваши проблемы... Но, вы должны были пойти к руководителю админа и разбираться с ним, т.к.:
Он расставил приоритеты админу и может их поменять
Ещё раз напомнить ему о его проблемах с персоналом
Ну и переложить ответственность все таки на того, кого надо, а не на бедного админа.
Сними корону... Что за принцесса: "мне он не нравится, исключите его из моего общения". Человек вам не анекдоты рассказывает, а решает рабочие моменты. Даже если это джун зелёный, который обращается к вашему сеньерскому величеству, ему нужно помочь, вы оба работаете над одной целью и в одной лодке.
В первый день выхода новичков устройте в офисе общекомпанейский завтрак. ... Организуйте в самом начале игру-знакомство...
Кому как, а я бы точно чувствовал себя максимально не уютно, если бы в первый мой день на работе собрали бы всю толпу поглазеть на меня, а потом еще заставили играть в какие-то игры... Предпочел бы начать знакомство с команды, постепенно расширяя свой круг общения. Но это я...
Там не уточнили, хотят одну базу данных или много БД, нужен ли кластер(kubernetes) или нет, нужна ли шина данных (kafka) или нет, stateless или statefull. Нужно ли всё максимально усложнять или нет. А какая нагрузка? Можно использовать популярные фреймворки или нужно собирать гоночный болид?
Кто там не уточнил? Статья похоже как раз про вас, перепутавших причины и следствия.
Вы поаккуратнее... Уделите немного времени теории, вы как минимум неправильно развиваете (а развиваете ли?) сердце. Бег на низком пульсе - это база! Сомневаюсь что 160-180 это ваши первые пульсовые зоны...
Так это что же получается... Во всех "нормальных" СУБД оптимизатор - это оптимизатор, а эти любители postgresql эту штуку назвали планировщиком и теперь всему свету пытаются навязать свое название и на собесах везде щеголяют столь вольным трактовками общепринятой терминологии... )))
Тогда ответ остается тот же с пояснением по "Между 5 и 6 все умирает". Сеансы имелись ввиду субд-шные, вытаскиваются запросом к системным таблицам/представлениям. если бд одна, то логично воспользоваться ее механизмами.
Потому что прошлое сообщение на какой-то на другой узел кластера или вообще в другой дата-центр ушло
Про распределенную систему не было ни слова, поэтому решение предложено в пределах 1 базы При распределенных вычислениях, думаю без координатора не обойтись, нам нужен сервис который возьмет на себя эту роль. Таким образом мы выносим обеспечение требований AСID с уровня БД, на уровень системы.
Между 5 и 6 все умирает. После восстановления cледующее повторные сообщения будут пытаться сделать работу заново, хотя она уже сделана.
Думаю придется выбирать компромисс: -Закрываем транзакцию после 6 пункта, но тогда все ждут пока идет работа... -Либо, что скорее всего предпочтительнее: быть готовым к повторной обработке (предусмотреть такую вероятность).
Делаем табличку-журнал с полями "id", "вид бизнес-задачи", "время начала", "время окончания", "id сеанса" + какой-нибудь "desc" по вкусу При запуске работает следующая логика (можно инкапсулировать в хранимку): 1 открываем транзакцию 2 идем в наш журнал и ищем незаконченную(время окончания is null) запись с нашим типом бизнес-задачи 3 Если не нашли: вставляем новую нашу запись о старте Если нашли, то берем id-сеанса и проверяем его существование. Если его уже нет завершаем(ставим дату окончания) с отметкой в desc что сеанс умер и вставляем нашу новую запись о старте. Если сеанс еще работает, то возвращаем соответствующее сообщение (в этом варианте - тут конец. закрыть транзакцию конечно надо). 4 Закрываем транзакцию 5 Выполняем нашу бизнес-задачу в новой транзакции, в случае ошибки - откатываем 6 Ставим отметку в журнале об окончании, можно в desc что-то написать (id сеанса скорее всего потребует еще дату начала сеанса для однозначной идентификации, в общем это особенности субд, в тексте упростил просто до id-сеанса)
Примерно так, если правильно понял задачу. Вроде должно работать
Тест не дает поменять выбранный уже ответ...
Не хватает вариантов типа "в тяжелой цифре все плохо, мечтаю свалить от сюда поскорее, но данный опыт на рынке не релевантный..."
Позвольте подушнить, но вы не правильно понимаете требования:
Масштабируемость - это как раз про увеличение нагрузки, а вы приводите пример про расширение функционала, это уже "Расширяемость" или "Гибкость" или "Устойчивость к изменениям"...
Законодательные и отраслевые требования - эти требования и стандарты напрямую влияют на систему, в том числе из таких требований часто вытекают и функциональные требования, поэтому это более чем обязательная зона ответственности системного аналитика, а не второстепенная, как вы ее пытаетесь представить. Хорошо если бизнес-аналитик сформирует вам их, но если нет, то системный аналитик должен это сделать сам.
Надёжность - пример типа "не более ... в такое-то время..." в 9-ках описывается требование по доступности, обычно оно не включает какие-то плановые простои, например на обслуживание, т.е. речь идет о сбоях, а их нельзя запланировать, поэтому указание промежутка времени здесь выглядит странно. Вы же скорее уже пытаетесь описать SLA.
Зарегистрировались чтобы написать этот комментарий? Ну-ну... Отзывы они такие отзывы...
Наверное и продукт то хороший, но вот такие методы продвижения сразу отталкивают.
Не понял про какую не свою работу вы говорите... И не надо никому рассказывать о чужих проблемах... Не продуктивно обхаживать админа который не хочет/не может сделать то что вы от него хотите. Мой сценарий:
РП: надо сделать то-то
Админ: Мне некогда, у меня другая задача
идем к начальнику админа/пишем с копией своего начальника...
РП: Мне от вашего админа надо то-то, он занят другим вашим поручением, у вас такие-то обязательства по проекту...
Начальник админа либо меняет приоритеты и дает задание админу, либо посылает вас так как его задача действительно важнее, беря ответственность на себя и в любом случае задумываясь в очередной раз о нехватке кадров и получая доп. аргумент для расширения штата. Вы при этом получаете официальный ответ и прикрытую задницу, все в плюсе, если эту ситуацию можно так назвать
Статью следовало бы назвать "как РП прикрыть свою задницу".
В описанной вами истории стало жалко админа, он и так 1 и зп у него маленькая и дел у него 100 одновременно, а вы его виноватым пытаетесь сделать. Конечно когда он увидит это (попытки оставить его крайним) он попытается пошевелиться, но это скорее всего будет в ущерб других его дел и он всё равно останется виноватым в другом месте. Реальная проблема в этой истории, то что кто-то не может обеспечить требуемое количество персонала, достойную ЗП, а возможно и квалификацию, но это все связано... Но это конечно не ваши проблемы... Но, вы должны были пойти к руководителю админа и разбираться с ним, т.к.:
Он расставил приоритеты админу и может их поменять
Ещё раз напомнить ему о его проблемах с персоналом
Ну и переложить ответственность все таки на того, кого надо, а не на бедного админа.
Сними корону... Что за принцесса: "мне он не нравится, исключите его из моего общения". Человек вам не анекдоты рассказывает, а решает рабочие моменты. Даже если это джун зелёный, который обращается к вашему сеньерскому величеству, ему нужно помочь, вы оба работаете над одной целью и в одной лодке.
Конечно! Используйте чистый git!
Кому как, а я бы точно чувствовал себя максимально не уютно, если бы в первый мой день на работе собрали бы всю толпу поглазеть на меня, а потом еще заставили играть в какие-то игры... Предпочел бы начать знакомство с команды, постепенно расширяя свой круг общения. Но это я...
не герметичные абстракции... ну-ну... Вы сами то читали это чудо, после Google Translate?
Кто там не уточнил? Статья похоже как раз про вас, перепутавших причины и следствия.
Интересно, сейчас в России кто-то всерьез рассматривает MS SQL как СУБД для новых разработок?
Зачем вам бинарный поиск, почему вы его вдруг лишились (а он был?) и почему именно он ощутим в больших таблицах?
Вы поаккуратнее... Уделите немного времени теории, вы как минимум неправильно развиваете (а развиваете ли?) сердце. Бег на низком пульсе - это база! Сомневаюсь что 160-180 это ваши первые пульсовые зоны...
Так это что же получается... Во всех "нормальных" СУБД оптимизатор - это оптимизатор, а эти любители postgresql эту штуку назвали планировщиком и теперь всему свету пытаются навязать свое название и на собесах везде щеголяют столь вольным трактовками общепринятой терминологии... )))
Узнайте в своей компании
Он будет висеть в ожидании пока не случится пункт 4. Т.е. работу не начнет. Таблица-журнал заблокирована же.
А у вас есть готовое решение этой задачи? Если есть, хотелось бы узнать его
Тогда ответ остается тот же с пояснением по "Между 5 и 6 все умирает". Сеансы имелись ввиду субд-шные, вытаскиваются запросом к системным таблицам/представлениям. если бд одна, то логично воспользоваться ее механизмами.
Про распределенную систему не было ни слова, поэтому решение предложено в пределах 1 базы
При распределенных вычислениях, думаю без координатора не обойтись, нам нужен сервис который возьмет на себя эту роль. Таким образом мы выносим обеспечение требований AСID с уровня БД, на уровень системы.
Думаю придется выбирать компромисс:
-Закрываем транзакцию после 6 пункта, но тогда все ждут пока идет работа...
-Либо, что скорее всего предпочтительнее: быть готовым к повторной обработке (предусмотреть такую вероятность).
Делаем табличку-журнал с полями "id", "вид бизнес-задачи", "время начала", "время окончания", "id сеанса" + какой-нибудь "desc" по вкусу
При запуске работает следующая логика (можно инкапсулировать в хранимку):
1 открываем транзакцию
2 идем в наш журнал и ищем незаконченную(время окончания is null) запись с нашим типом бизнес-задачи
3
Если не нашли: вставляем новую нашу запись о старте
Если нашли, то берем id-сеанса и проверяем его существование. Если его уже нет завершаем(ставим дату окончания) с отметкой в desc что сеанс умер и вставляем нашу новую запись о старте. Если сеанс еще работает, то возвращаем соответствующее сообщение (в этом варианте - тут конец. закрыть транзакцию конечно надо).
4 Закрываем транзакцию
5 Выполняем нашу бизнес-задачу в новой транзакции, в случае ошибки - откатываем
6 Ставим отметку в журнале об окончании, можно в desc что-то написать
(id сеанса скорее всего потребует еще дату начала сеанса для однозначной идентификации, в общем это особенности субд, в тексте упростил просто до id-сеанса)
Примерно так, если правильно понял задачу. Вроде должно работать