Вот интересно, а где в России используется в банках cobol. Я вот все время с банками работаю уже 15+ лет и cobola нигде ее видел. Есть какой-то продукт может который на cobol?
А почему не хранимые процедуры? Они более безопасны (можно раздавать права на запуск например) и они хранят готовый план, т.е. должны быть более эффективны.
В запросах с like лучше стараться использовать field like 'patt%' , так есть шанс попасть в индекс, а при использовании field like '%patt%' индекс не по полю field скорее всего не будет использоваться.
У нас нужно ежедневно списываться и есть отчет который показывается все списания за любой день. А если не списываться вовремя, то немного падает kpi и это влияет на бм. Поэтому обычно новички вначале ворчат, но через пару месяцев втягиваются и не испытывают с этим больших сложностей.
А если у нас все в таблицу записано, то что мешает пары create-delete в разрезе идентификатора объекта убрать из этой таблицы до отправки в elastic? Все равно по итогу ничено не останется в elastic.
Интересно, какой тут расход воды, чтобы всю скважину заполнить и плюс потери компенсировать. Ну и вода наверное быстро превратится в очень агрессивный солевой раствор и из чего нужно будет оборудование для станции делать, чтобы оно долго служило. И наверняка еще с водой будет много газа выходить из скважины и возможно радиоактивного.
У МТС недавно была задача на поиск простых 11-значных чисел среди примерно 4 миллионов. В лоб это занимало 15 мин, интересно с этим алгоритмом проверить.
Если в интерфейсе нужно показать лукап с типами, например для фильтрации счетов, то как быть? В случае с таблицей каждому типу можно хранить человекочитаемую расшифровку, что удобно для показа в ui.
А почему решили использовать брокер сообщений? Если взаимодействие у вас асинхронное, то и rest может параллелится через балансировщик. Можно же точно также по rest-у вначале в базу записать транзакцию, а затем обработать в другом потоке.
Тут не рассмотрен момент, когда нужно обеспечить иммутабельность переданных данных. Передача по ссылке имеет кучу побочки, которую трудно отследить. Это почти как глобальные переменные. В одном месте случайно поменял, а выстрелило в другом. У нас был кейс, когда в одной функции переданный по ссылке объект удалили, сделали ему free. А потом чуть ниже из-за этого все палало с AV за пределами этой функции.
А кто будет тесты на код нейронки писать, то же нейронка? Насколько это будут правильные тесты?
Ну или например нейронка обучена на некотором количестве плохих примеров и в некоторых случаях дает не оптимальный или не безопасный код. Джуна можно легко обучить, просто сказать что почитать или где посмотреть, а с сеткой это так просто не фиксится.
Ошибки находятся тестами. Человек сам их чинит, когда видит что тест упал, а сетку еще убедить нужно что есть ошибка. Т.е. нейронка сама не может пойти и ошибки пофиксить или код порефакторить. Инициатор всегда живой человек и он же должен следить за результатом.
А еще люди стресс заедают. И возможно это дпже чаще чем при болезни. Может нужно это чекать и смотреть что с загрузкой и какая атмосыера в команде.
Вот интересно, а где в России используется в банках cobol. Я вот все время с банками работаю уже 15+ лет и cobola нигде ее видел. Есть какой-то продукт может который на cobol?
Если все работает, то нужно просто бороться с энтропией. Она всегда растет.
А почему не хранимые процедуры? Они более безопасны (можно раздавать права на запуск например) и они хранят готовый план, т.е. должны быть более эффективны.
В запросах с like лучше стараться использовать field like 'patt%' , так есть шанс попасть в индекс, а при использовании field like '%patt%' индекс не по полю field скорее всего не будет использоваться.
У нас нужно ежедневно списываться и есть отчет который показывается все списания за любой день. А если не списываться вовремя, то немного падает kpi и это влияет на бм. Поэтому обычно новички вначале ворчат, но через пару месяцев втягиваются и не испытывают с этим больших сложностей.
Странно, но мне чаще встречаются лиды, которые в основном подкручивают kpi, чтобы получать БМ и это не зависит от конторы. Есть и банки и вендоры.
Ну в таблицу PG оно пишется в правильном порядке. Это после прокачки через брокер порядок может нарушится.
А если у нас все в таблицу записано, то что мешает пары create-delete в разрезе идентификатора объекта убрать из этой таблицы до отправки в elastic? Все равно по итогу ничено не останется в elastic.
Интересно, какой тут расход воды, чтобы всю скважину заполнить и плюс потери компенсировать. Ну и вода наверное быстро превратится в очень агрессивный солевой раствор и из чего нужно будет оборудование для станции делать, чтобы оно долго служило. И наверняка еще с водой будет много газа выходить из скважины и возможно радиоактивного.
У МТС недавно была задача на поиск простых 11-значных чисел среди примерно 4 миллионов. В лоб это занимало 15 мин, интересно с этим алгоритмом проверить.
Если в интерфейсе нужно показать лукап с типами, например для фильтрации счетов, то как быть? В случае с таблицей каждому типу можно хранить человекочитаемую расшифровку, что удобно для показа в ui.
А почему решили использовать брокер сообщений? Если взаимодействие у вас асинхронное, то и rest может параллелится через балансировщик. Можно же точно также по rest-у вначале в базу записать транзакцию, а затем обработать в другом потоке.
Спасает. Только об этом не сказано в статье. Там как-то однобоко. Минусы описаны, а плюсы нет.
Тут не рассмотрен момент, когда нужно обеспечить иммутабельность переданных данных. Передача по ссылке имеет кучу побочки, которую трудно отследить. Это почти как глобальные переменные. В одном месте случайно поменял, а выстрелило в другом. У нас был кейс, когда в одной функции переданный по ссылке объект удалили, сделали ему free. А потом чуть ниже из-за этого все палало с AV за пределами этой функции.
А если в пылу игры зажать случайно две кнопки, то срабатывать всегда будет та, что ближе к резистору R1?
Можно вот такой индекс сделать
CREATE UNIQUE INDEX line_doc ON line (docid, id);Должно быть лучше, если в индекс
line_docдобавить поле id и сделать этот индекс уникальным.А кто будет тесты на код нейронки писать, то же нейронка? Насколько это будут правильные тесты?
Ну или например нейронка обучена на некотором количестве плохих примеров и в некоторых случаях дает не оптимальный или не безопасный код. Джуна можно легко обучить, просто сказать что почитать или где посмотреть, а с сеткой это так просто не фиксится.
Мешает это сделать высокая сложность написания таких тестов и то, что мало кто понимает как НС находят решения, если вообще кто-то это понимает.
Ошибки находятся тестами. Человек сам их чинит, когда видит что тест упал, а сетку еще убедить нужно что есть ошибка. Т.е. нейронка сама не может пойти и ошибки пофиксить или код порефакторить. Инициатор всегда живой человек и он же должен следить за результатом.