На каком уровне нужно знать SQL разработчику .NET?

Ievgen 11.12.2019 23:50

.NET-разрабу хотя бы на уровне вот этой книги
Itzik Ben-gan: Microsoft SQL Server 2012 T-SQL Fundamentals

Відповісти

Підтримати

anonymous 07.12.2019 14:36

-

Відповісти

Підтримати

Yurii Luchkiv Software Engineer в Tech1 03.12.2019 08:16

На такому, щоб він був задоволений своєю зарплатою :)

Відповісти

Підтримати

Владислав Фурдак CEO в Nearshore Devs 27.11.2019 23:39

Зависит от проекта. Очень сильно зависит от проекта.

Відповісти

Підтримати

Александр Шевченко 27.11.2019 09:24

джуниор с 8 годами опыта? ))

Відповісти

Підтримати

proger 26.11.2019 00:49

нужно-ненужно это плохо поставленный вопрос, есть вакансии где нужно, есть — где не нужно :)
с моей колокольни — базы разнообразят жизнь, там довольно интересно, особенно после запросов к таблицам на 100+млн записей, и, ну удивление, платят за это больше

Відповісти

Підтримати

Denis Reznik Data Architect в Intapp 25.11.2019 19:55

Надо или не надо сказать не могу (это очень субъективно), но могу сказать что знания эти полезные.

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

P.S. Саму статистику использования реляционных баз данных вижу так:
1) Большинство проектом имеют хранилище данных
2) Большинство проектов из пункта 1 имеют хранилище сложнее чем просто файлы на диске
3) Большинство проектов из пункта 2 хранят данные в реляционных базах данных.

Відповісти

Підтримати

Konstantin Strukov 26.11.2019 11:16

Даже если придётся работать с Монгой или Кассандрой, знание реляционных баз поможет быстрее разобраться и построить эффективное решение.

Скорее, помешает :)

Відповісти

Підтримати

Denis Reznik

Андрей Литвинов C Señor 26.11.2019 11:20

В моем случае очень даже пригодился опыт исследования плана запросов, понимание индексов и подобных внутренностей. В NoSQL нужно больше задумываться о границах транзакций и атомарности, что приводит к более качественному дизайну или perpetual inconsistency вместо eventual consistency 😜.

Відповісти

Підтримати

Konstantin Strukov

anonymus ps 27.11.2019 08:04

часто наблюдаю когда люди строят 3 нормальную форму в монго ;(

Відповісти

Підтримати

Андрей Литвинов

Андрей Литвинов C Señor 27.11.2019 08:09

Грустяшка, да. Но обновление референсов на другие документы (которые включают не только id, но и некоторые дополнительные данные, чтобы не вытаскивать другие документы без необходимости) тоже нетривиальная штука (казалось сначала), наша команда не сразу пришла к пониманию как это нормально делать. Event-Driven архитектура и eventual consistency очень адекватное решение для этого.

Відповісти

Підтримати

anonymus ps

Sеrgеу Bоrуssenkо Senior Tractorist 27.11.2019 10:43

Вообще понятие «широкий кругозор» и «разнообразный опыт» оно не только в жизни помогает видеть лучше картину и принимать более взвешенные решения. В работе это тоже в полной мере, поэтому довольно глупо выглядят люди, которые вместо того, чтобы разобраться в чем-то нужном для своей работы говорят «это не моя зона ответственности! Я бекендщик, нафига мне ваши корсы?»

Відповісти

Підтримати

Андрей Литвинов

Konstantin Strukov 27.11.2019 10:59

Я согласен с тем, что

опыт исследования ... внутренностей.

как говорицца «не пропьешь», но вот конкретные знания о том, «как правильно делать» переносятся плохо. Де-факто, проектировать модель данных для nosql отталкиваясь от «я сто раз так в постгресе делал» — это верный способ отстрелить себе все конечности. Самый свежак в моей коллекции такого рода граблей — это пассажир, который пытался прикрутить в кластер кассандры вторичный индекс по уникальному полю потому что он «сто раз так делал [в реляционках] и хуже точно не будет» (и вообще он локально потестил [на одной ноде, разумеется — для дев. окружения больше поднимать накладно очень] и всё отлично работает).

Відповісти

Підтримати

Андрей Литвинов

Андрей Литвинов C Señor 27.11.2019 11:01

Я ни в коем случае не предлагал опыт реляционок портировать 1:1 на NoSQL 🙂.

Відповісти

Підтримати

Konstantin Strukov

IRD Software developer в PE 22.11.2019 14:04

а чо такого? тыжпрограммист или как?

Відповісти

Підтримати

anonymous 22.11.2019 14:09

-

Відповісти

Підтримати

IRD

Denys Poltorak Embedded | C++ (opentowork) 22.11.2019 14:14

Стартап?

Відповісти

Підтримати

anonymous

Bot Bot 22.11.2019 15:25

Утюг почини!

Відповісти

Підтримати

anonymous

anonymous 22.11.2019 18:49

-

Відповісти

Підтримати

Bot Bot

IRD Software developer в PE 23.11.2019 09:06

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

Відповісти

Підтримати

anonymous

IRD Software developer в PE 23.11.2019 09:02

да как два пальца обос*ть.
но дорого, программисты нынче зажрались

Відповісти

Підтримати

anonymous

Sergii Syrovatchenko SQL Server DBA 22.11.2019 09:29

Реально ли так нужны знания RDBMS и SQL?

Исходя из своего опыта очень редко встречаются разработчики которые хотя бы поверхностно знают базы и могу писать качественный код на SQL. Хотя формально для этого не нужно много учиться. Нужен лишь базовый синтаксис + понимание того как все работает, а это все покрывает одна книга в стиле Pro SQL Server Internals.

Відповісти

Підтримати

Олександр Мощенко 22.11.2019 09:51

много учиться не надо. Всего одна книжка. на 800 страниц.
«генту можно поставить всего одной консольной командой» (ц)

Відповісти

Підтримати

Sergii Syrovatchenko

Left Outer Join 22.11.2019 13:44

Всего одна книжка. на 800 страниц.

И что? Это много?

Відповісти

Підтримати

Олександр Мощенко

Олександр Мощенко 22.11.2019 13:51

Математический анализ. В 2-х томах. Ильин В.А., Садовничий В.А., Сендов Бл.Х.
М.: Изд-во МГУ. Ч.1: 2-е изд., перераб., 1985. — 662с.; Ч.2 — 1987. — 358с.
матанализ всего на 200 страниц больше.

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

Відповісти

Підтримати

Left Outer Join

Nik Katalnikov explorer 25.11.2019 13:09

пример так себе, очень на любителя чтиво.
Кудрявцев намного лучше для студентов и инженеров. не говоря уже о книгах Стренга или Строгаца.

Відповісти

Підтримати

Олександр Мощенко

Dmitry Bugay 22.11.2019 11:28

не нужно много учиться

покрывает одна книга

SQL Server DBA

:)

Відповісти

Підтримати

Sergii Syrovatchenko

Andrii Tkachenko .Net developer at Lime Systems 22.11.2019 08:57

Вполне достаточно на базовом уровне. Выборки, фильтрации, инсерты, апдейты и все такое. иногда джойны или функции. Для написания реально сложных скриптов с кучей релейшенов ядумаю уже должен быть DBA. Каждый должен заниматься своим делом. Full -Stack кстати это тоже иллюзия. Все равно ты что то будешь знать значительно хуже, а что -то значительно лучше. ИМХО, лучше быть профи в чем то одном: бэк-енд или фронт-енд. Но конечно, бэк-енд разраб все равно будет работать со фронтом и знать JS хотя бы на уровне дебага бэк-енд должен, но фронт-енд разработчика он все равно не переплюнет. И соотвестенно наооброт. (я о фронт-енд разработчике)

Відповісти

Підтримати

anonymous 22.11.2019 15:41

-

Відповісти

Підтримати

Andrii Tkachenko

Yuryi ,Net developer 22.11.2019 20:19

ответ на этот вопрос человек получит через 10 секунд после попытки использовать функцию..

Відповісти

Підтримати

anonymous

Александр Липских Oracle Developer в UNITY-BARS 07.12.2019 08:55

Эм... Ваш вариант?

Відповісти

Підтримати

anonymous

aa aa 21.11.2019 23:59

Знание SQL и знание RDBMS это разные вещи. Натравить presto/bigquery на тонну данных

Я считаю что SQL очень помогает (как и регэксы и базовый pandas/numpy/scipy) для exploratory data analysis. А в работе разработчика необходимость такого анализа всплывает регулярно — перелопатить тонну логов, разобраться с причинами и т.д.

Уровни изоляции это может быть уже лишним, а вот умение написать несложный запрос всегда пригодится. Под несложным я понимаю именно select без хранимок со всякими

join/where/group by/having/аналитические функции (partition by)/подзапросы

Відповісти

Підтримати

Hryhorii Koval .NET Developer в Jabil Software Services 21.11.2019 22:22

8 лет опыта без SQL? Ты стебëшься?

Відповісти

Підтримати

Vadim Kopanev Architect 21.11.2019 22:25

Я таких людей знаю, очень редко, но бывает, буквально один из тысячи

Відповісти

Підтримати

Hryhorii Koval

Serhii 21.11.2019 19:54

Может ли разработчик считаться фуллстеком, если он не знает SQL?

Відповісти

Підтримати

Valeriy Shvets Engineer в Phonexa 21.11.2019 23:45

В принципе, сейчас наверное да, хранилище не обязательно должно быть реляционным (mongodb как вариант). Но, даже в этом случае нужно понимать что такое индексы, составные, какие операции они ускоряют, чтоб ради получения одной записи/объекта не сканилась вся коллекция на 100500+ элементов.

И желательно представлять что происходит при конкурентном доступе в разных кейсах (read/write). Хотя если 100 человек в день пользуются проектом, то и не обязательно.

Відповісти

Підтримати

Serhii

Vladimir Kovrigin Теоретик 04.12.2019 08:47

Индексы не только в RDBMS есть, а в практически любом хранилище :)

Відповісти

Підтримати

Valeriy Shvets

Valeriy Shvets Engineer в Phonexa 04.12.2019 09:12

я в этом контексте и писал

Відповісти

Підтримати

Vladimir Kovrigin

Bot Bot 21.11.2019 17:01

Ну обычно чисто .Net не часто встречается, обычно помимо .Net еще приходится месить или js или t-sql, а то и все сразу, на чьей стороне будешь ты, выбирать тебе.
Как хорошо? Ну зависит от собеседования, что там тебя спрашивать будут и сколько денег предложат, дальше обычно всем пофиг.

Відповісти

Підтримати

Lyova Zi 22.11.2019 08:33

помимо .Net еще приходится месить

CSS, HTML, JavaScript, TypeScript, SQL, T-SQL, PL/SQL, XAML, NoSQL etc

Відповісти

Підтримати

Bot Bot

Bot Bot 22.11.2019 15:29

Та я и WebGL с шейдерами(элементарными правда) и VBA макросы и еще какую-то дичь на энтерпрайзах месил что даже названий не помню.

Відповісти

Підтримати

Lyova Zi

Stanislav Demchenko Senior Java Developer в iX.co 21.11.2019 00:47

Бэкендщик всегда может найти проект по своим предпочтениям: с SQL или без, с JS или без, и т.п.
Без хороших знаний SQL бэкендщика могут не взять на какой-то специфичный проект, но может не очень-то и хотелось.
Доступных проектов море, и в наше время бэкендщику знания SQL нужны в минимальном объеме, потому что на большинстве проектов:
— либо только простейший SQL,
— либо есть выделенный database developer, который пишет весь сложный SQL,
— либо вообще не используется SQL, например потому, что все данные в noSQL или очередях, или в сторонних REST-сервисах.
Есть желание — можно учить глубоко. А нет желания, то и ладно.

Відповісти

Підтримати

Seven Berg 21.11.2019 15:22

Не не согласен, БД знать надо хотя бы на уровне как связать таблицы. Может пригодиться, когда велосипеды пишешь...

Відповісти

Підтримати

Stanislav Demchenko

Stanislav Demchenko Senior Java Developer в iX.co 21.11.2019 16:27

бэкендщику знания SQL нужны в минимальном объеме

подразумевает знание джойнов, тем более что любой ORM их тоже подразумевает.

Відповісти

Підтримати

Seven Berg

Seven Berg 21.11.2019 00:45

join всякие наверное

Відповісти

Підтримати

Sеrgеу Bоrуssenkо Senior Tractorist 20.11.2019 22:33

Ну если за 8 лет не пришлось столкнуться то можно ещё 8 лет проработать и не столкнуться :)

Відповісти

Підтримати

Vladimir Petryshyn Senior Database Developer в Trinetix 20.11.2019 19:27

На уровне junior database developer:
Джойны
Хранимые процедуры, вьюшки
Основы индексов, какие бывают и зачем
Что такое дедлоки и тд

Відповісти

Підтримати

ТЗ 20.11.2019 20:53

хм... сразу к дедлокам минуя локи?
или слово страшнее звучит?

Відповісти

Підтримати

Vladimir Petryshyn

Vladimir Petryshyn Senior Database Developer в Trinetix 20.11.2019 22:25

Разбираясь что такое дедлоки по пути узнаете что такое транзакции, уровни изоляций, блокировки и тд

Відповісти

Підтримати

ТЗ

Alexandr Gavriluk .Net developer в Aspose 21.11.2019 08:24

блокировки

Это если сервер блокировочник, а если версионник то там совсем другие грабли.

Відповісти

Підтримати

Vladimir Petryshyn

Valeriy Shvets Engineer в Phonexa 21.11.2019 09:09

Так блокировки и в версионнике есть. Иначе при параллельных транзакциях с апдейтами каша получалась бы и само понятие дедлоков в них отсутствовало, но нет

Відповісти

Підтримати

Alexandr Gavriluk

anonymus ps 27.11.2019 08:06

Хранимые процедуры

а вот это точно не обязательно — можно знать что есть — но лучше если больше не знаешь — соотвественно не используешь

Відповісти

Підтримати

Vladimir Petryshyn

Олександр Мощенко 27.11.2019 09:15

пересчитывать агрегаты в коде приложения или копипастить содержимое триггеров. Что может быть интереснее.

Відповісти

Підтримати

anonymus ps

anonymus ps 27.11.2019 09:59

И ещё два плохих примера — агрегаты — ты скорее нуждаешься в olap, тригеры добавляют ещё больше проблем, чем решают — есть может от сил 1-2 юз кейса для них но они обычно крайне редки и там хранимки не нужны

Відповісти

Підтримати

Олександр Мощенко

Олександр Мощенко 27.11.2019 10:10

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

Відповісти

Підтримати

anonymus ps

anonymus ps 27.11.2019 10:14

Не любая денормализация есть агрегатом.
Проблема в том что когда часть делается в коде а часть в бд то ты сразу создаёшь проблему, и это не религия — это нежелание быть поднятым в 4 утра и фиксит прод после таких решений

Відповісти

Підтримати

Олександр Мощенко

Олександр Мощенко 27.11.2019 10:27

про нормальность я поправился. Я имел ввиду логическую целостность данных. Промежуточные итоги, счётчики, въюхи, валидация — это всё данные, и работать с ними удобно на уровне данных. И если у тебя триггер не даёт выполнить действие, то это действие и не будет выполнено даже если в коде кто-то закомментит (// todo раскомменть в проде!) проверку. И тебя не будут будить в 4 утра.

Відповісти

Підтримати

anonymus ps

Андрей Литвинов C Señor 27.11.2019 10:29

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

Відповісти

Підтримати

Олександр Мощенко

Олександр Мощенко 27.11.2019 10:40

Почему прямо всё? часть проверок вполне может быть актуальна в пределах ноды. Например если данные пользователя у тебя на одной ноде.
Опять же, когда нужно будет масштабироваться горизонтально, то вопрос «надо ли знать эскуэль» отпадёт сам собой — кроме эскуэля и триггеров там будет купа новых модных проблем. И человек, способный нормально организовать работу этой системы, наверняка будет знать и эскуэль, и триггеры, и транзакции и всё вот это вот всё.

Відповісти

Підтримати

Андрей Литвинов

Андрей Литвинов C Señor 27.11.2019 10:42

Именно. И не будет использовать триггеры и хранимки как единственно-верное решение, а будет к ним прибегать только в случае крайтей необходимости.

Відповісти

Підтримати

Олександр Мощенко

Олександр Мощенко 27.11.2019 10:56

согласен со всем, кроме использования слова «крайний». Только ситхи возводят всё в абсолют.
Когда сервис строится и активно меняется — обычно используется одна бд, вынести в которую логику, относящуюся к данным, вполне, имхо, логично. Схема данных меняется значительно реже обрабатывающего эти данные кода, потому такой способ позволит полагаться на целостность данных. Да, в будущем возможно понадобится переделать это. А может и не понадобится. Не каждая птица доживёт до момента горизонтального масштабирования.

И потому весь функционал субд достоен внимания, а максимы а-ля «триггеры и хранимки только в самых крайних случаях» спорны.

Відповісти

Підтримати

Андрей Литвинов

Андрей Литвинов C Señor 27.11.2019 10:59

Юный падаван еще не сталкивался с проблемами версионирования и координации релизов между сервисом и бд, когда деплой сервиса ломает логику хранимки или изменение храрнимки/триггера ломают логику приложения?

Відповісти

Підтримати

Олександр Мощенко

Олександр Мощенко 27.11.2019 11:10

Юный падаван старается не ломать то, что работает. И если кто-то реализовал работу с данными так, что их не хочет пропускать триггер в бд, то штош. Наверное тут ничего не поделать, ктоме как дроп триггер сделать.

Відповісти

Підтримати

Андрей Литвинов

Sеrgеу Bоrуssenkо Senior Tractorist 27.11.2019 10:47

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

Поправил :)

Відповісти

Підтримати

Андрей Литвинов

anonymous 28.11.2019 08:15

-

Відповісти

Підтримати

Андрей Литвинов

Андрей Литвинов C Señor 28.11.2019 08:22

Попробуй посмотреть на MySQL или Postgres. Даже Oracle и MS SQL якобы масштабируются горизонтально, но это стоит одуренных денег.

Но я говорил про горизонтальное масштабироваение сервисов, а не бд.

Відповісти

Підтримати

anonymous

Дмитро 28.11.2019 09:41

Значит слабо разбираетесь в вопросе. На чтение скейлиться вообще элементарно, на запись сложней — клиентская либа и будет почти тоже самое что монга, но даже здесь уже есть решения поддерживающие multi-master write конфигурацию со стороны сервера, что ушло куда подальше чем многие nosql решения по типу монги редиса и тд.

Відповісти

Підтримати

anonymous

Андрей Литвинов C Señor 28.11.2019 10:27

Монга на запись вообще не скейлится, у неё только один мастер принимает записи, если не использовать шарды.

Відповісти

Підтримати

Дмитро

Дмитро 28.11.2019 10:36

Поэтому сиквел с репликацией и клиентским шардированием будет та же самая монга с шардами только без chunk split и redistirbution.

Відповісти

Підтримати

Андрей Литвинов

Андрей Литвинов C Señor 28.11.2019 10:53

без chunk split и redistirbution

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

Відповісти

Підтримати

Дмитро

Дмитро 28.11.2019 11:12

Т.е. придется самому присать?

зачем писать — без этого можно спокойно жить. просчитать формулу ключа для максимально even дистрибуции по данными между шардами и все.

А реляции между таблицами?

Так же как и в монго — решается на этапе дизайна и имеет те же ограничения, монго тут ничего предложить тоже не может. $lookup тоже не работает для шардированных коллекций.
По факту это не есть техническим ограничением для шардирования как такового, единственная разница делается на клиенте и закладывается на этапе дизайна.

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

берется ключ партицированния на самом верхнем уровне иерархии, а реляции на более низком дизайнятся. например country id, а все реляции подчиненные идут — регионы, районы, города, районы, магазины и т.д.

Главный поинт тут в том, что для монго это более натуральный вариант использования чем для сиквела — шардирование. но монго предложить больше чем сиквел тут не может ничего.

Відповісти

Підтримати

Андрей Литвинов

Андрей Литвинов C Señor 28.11.2019 11:13

Я про добавление нового шарда в кластер.

Відповісти

Підтримати

Дмитро

Дмитро 28.11.2019 11:27

А что mongo умеет на сервере делать consistent hashing? мне казалось там такой же механизм партицирования как я описал выше — hash/range partitioning. По сути полное репартицирование, что там что там.

Відповісти

Підтримати

Андрей Литвинов

Андрей Литвинов C Señor 28.11.2019 11:29

Там нет consistent hashing, но она умеет ребалансиваться при добавлении нового шарда. В случае самописйной реализации, про которую ты говорил выше, это так же нужно будет реализовывать самому.

Відповісти

Підтримати

Дмитро

Дмитро 28.11.2019 11:34

Это не надо делать самому, как я сказал для этого есть готовый тулинг.
docs.microsoft.com/...-overview-split-and-merge

Відповісти

Підтримати

Андрей Литвинов

Андрей Литвинов C Señor 28.11.2019 11:36

Значит я не правильно понял формулировку «шардинг на клиете». Выглядит очень страшно, если честно. Мне бы очень не хотелось в такое ввязываться. И очень дорого. Лучше решать на уровне дизайна приложения и выделения адекватных поддоменов.

Відповісти

Підтримати

Дмитро

Дмитро 28.11.2019 11:44

Azure SQL кстати очень выгодное по деньгам решение — у них есть такая штука как elastic pool(не уверен но помоему у AWS такого нет). платите деньги за набор баз в различных датацентрах и платите pay as you go полностью под нагрузку на все эти базы сколько вам надо из общего пулла проплаченных ресурсов ресурсов аллоцируется оно(даже на разные регионы). при правильной конфигурации будет максимально экономно и с минимум головняка. попробуйте такое сделать с наборотм датацентров в он-прем и посчитать солько это будет стоить при сопоставимой нагрузке. Мы, правда, не юзаем шардинга для сиквела. нам просто оно без необходимости. но с такими возможностями я уверен что шардинг там с точки зрения денег вообще не проблема(будет гибче и стоить точно меньше чем dynamo, cosmos и тому подобное). С точки зрения заморочек — уже надо смотреть.

Відповісти

Підтримати

Андрей Литвинов

anonymous 28.11.2019 11:31

-

Відповісти

Підтримати

Дмитро

Дмитро 28.11.2019 11:52

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

Відповісти

Підтримати

anonymous

anonymous 28.11.2019 10:27

-

Відповісти

Підтримати

Дмитро

Дмитро 28.11.2019 10:49

в сиквеле это делается на стороне клиента спокойно, как я описал выше.

Відповісти

Підтримати

anonymous

Андрей Литвинов C Señor 28.11.2019 10:54

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

Відповісти

Підтримати

Дмитро

Дмитро 28.11.2019 11:21

не очень понимаю чем тут монго поможет принципиально больше например. Самые «невелосипедные» решения для этого dynamo, cassandra, riak что умеют в multimaster. Беспроблемно будут решаться задачи, что нормально ложатся на использование «типов данных где отсуствуют конфликты» (CRDT), все остальное это либо потеря данных либо ручное разрешение конфликтов даже в multimaster. Подходящего простого решения тут просто не существует, для задач что чуть более сложные чем посчитать общее количетсво лайков.

Відповісти

Підтримати

Андрей Литвинов

Андрей Литвинов C Señor 28.11.2019 11:22

Мы про multimaster или шардирование на клиенте? А то я, наверное, потерял нить дискуссии.

Відповісти

Підтримати

Дмитро

Дмитро 28.11.2019 11:31

Я полагаю речь о том как отскейлить горизонтально базу данных и иметь меньше заморочек и проблем с этим. И шардинг и multimaster и репликация все в той или инной степени об этом.

Відповісти

Підтримати

Андрей Литвинов

Андрей Литвинов C Señor 28.11.2019 11:33

Это два совсем разных подхода. В multimaster я пока не вникал, поэтому не могу ничего умного сказать на этот счет 🙂.

Відповісти

Підтримати

Дмитро

Left Outer Join 20.11.2019 09:42

Но ведь реляционные базы данных вы должны были проходить в университете

Відповісти

Підтримати

Seven Berg 23.11.2019 21:19

Теория реляционных баз данных, по моему так называется...

Відповісти

Підтримати

Left Outer Join

Вавилен Татарский 20.11.2019 09:20

Дуже залежить від проекту, вистачає таких де більша частина логіки з тих чи інших причин винесена в базу даних. Кілька років працював на проекті де 70% часу займався саме SQL.

Відповісти

Підтримати

Андрей Литвинов C Señor 20.11.2019 06:37

Может, конечно, повезет и в компании будет использоваться какая-то монга или касандра, но в общем случае бэкенд разработчику бд нужно знать достаточно хорошо.

Відповісти

Підтримати

Andy W 20.11.2019 18:08

повезет

монга или касандра

це жарти такі?

Відповісти

Підтримати

Андрей Литвинов

Андрей Литвинов C Señor 20.11.2019 18:11

Не, эт такие базы данных. Некоторым везет с ними работать вместо ковыряний в SQL.

Відповісти

Підтримати

Andy W

anonymous 20.11.2019 18:57

-

Відповісти

Підтримати

Андрей Литвинов

Андрей Литвинов C Señor 20.11.2019 19:01

Если схема фиксирована, зачем их использовать.

Если код компилится зачем его трогать.
Я имел в виду не SQL-подобный язык, как таковой, а как раз, заморочки со схемами, join-ами и всем, что идет вместе с этим. Я инженер-программист, я нехочу схемы бд, я хочу моделировать предметные области.

Відповісти

Підтримати

anonymous

Left Outer Join 20.11.2019 19:16

Я инженер-программист, я нехочу схемы бд, я хочу моделировать предметные области.

кхм-кхм

Відповісти

Підтримати

Андрей Литвинов

ТЗ 20.11.2019 20:54

любой солдат хочет стать -генералом- (архитектором)

Відповісти

Підтримати

Left Outer Join

Владимир Кожаев 20.11.2019 22:39

Ну вот я моделирую с помощью dsl, думаешь мне не надо знать как написать запрос?

Відповісти

Підтримати

Left Outer Join

Denis Reznik Data Architect в Intapp 25.11.2019 19:04

да

Відповісти

Підтримати

Владимир Кожаев

anonymous 20.11.2019 19:20

-

Відповісти

Підтримати

Андрей Литвинов

Андрей Литвинов C Señor 20.11.2019 19:22

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

Відповісти

Підтримати

anonymous

Dmitry Bugay 20.11.2019 22:13

я нехочу схемы бд

а зря )

я хочу моделировать предметные области.

У нас уже был спор примерно на эту тему :)

Відповісти

Підтримати

Андрей Литвинов

Андрей Литвинов C Señor 20.11.2019 22:52

Ага. Вот, кстати, норм доклад на тему www.youtube.com/watch?v=1fjGPG-v76s.

Відповісти

Підтримати

Dmitry Bugay

Konstantin Strukov 21.11.2019 15:22

Некоторым везет с ними работать вместо ковыряний в SQL.

Ну хз. Ковыряний с той же Кассандрой ничуть не меньше, просто они другие, и от некоторых пригорает несоизмеримо сильнее, чем от ковыряния в сиквеле.

Відповісти

Підтримати

Андрей Литвинов

Андрей Литвинов C Señor 21.11.2019 15:24

Я иметь в виду схемы. Моделируя предметную область не хочется зависить от ограничений БД или думать по каким табличкам что куда разложить. В этом плане NoSQL или EventStore идеальны.

Відповісти

Підтримати

Konstantin Strukov

Dmitry Bugay 21.11.2019 15:37

Моделируя предметную область не хочется зависить от ограничений БД

Так не завись. Моделируй БД как захочешь. Не ОРМ единым. А даже если ОРМ — оно ограничивает тебя, только если делать ровно-так-как-написано-в-туториале.

Відповісти

Підтримати

Андрей Литвинов

Андрей Литвинов C Señor 21.11.2019 15:39

Так я и не завишу, я уже больше двух лет счастливый пользователь MongoDB 😜.

Відповісти

Підтримати

Dmitry Bugay

Sеrgеу Bоrуssenkо Senior Tractorist 22.11.2019 12:03

Те же яйца только в профиль. Все равно в голове нужно иметь картину как хранить данные, чтобы все вместе эффективно работало. Просто это называется неосознанная компетентность — когда не отдаешь себе отчет сколько решений принимается уже на автомате, думая, что все просто.

Відповісти

Підтримати

Андрей Литвинов

Андрей Литвинов C Señor 22.11.2019 14:37

У моем случае она осознанная 🙂. Мой простой посыл в том, что схемы добавляют оверхеда, без которого можно обходиться.

Відповісти

Підтримати

Sеrgеу Bоrуssenkо

Maksym Riabov MS SQL Server DBA в Aspireglobal 22.11.2019 17:58

счастливый пользователь MongoDB

бугагашенька, знал я таких счастливчиков которые после года активного использования монги в проде начинали смотреть на традиционные СУБД
ведь внезапно оказывалось, что данные не только писать нужно, но и читать и тут все становилось печально — в то время у монги даже джоинов не было (хз завезли ли их в монгу сейчас).
ЗЫ в целом против монги я ничего особо не имею — такой себе нишевый продукт, который в своей нише пожалуй неплох.
а вот тех, кто пытается сложные базы запихнуть в монгу мотивируя тем что не надо париться со схемами, простотой масштабирования и т.д. — надо гнать сцаными тряпками.

Відповісти

Підтримати

Андрей Литвинов

Андрей Литвинов C Señor 22.11.2019 18:04

Бугагашенька 😁. Но опыт у все разный, это да.

Відповісти

Підтримати

Maksym Riabov

Konstantin Strukov 21.11.2019 15:49

Ну тогда кассандра не зайдет, и из списка «повезло» ее нужно выпиливать :) С ней нужно очень хорошо думать над структурой (а, точнее, вообще над тем нужна ли тут кассандра) данных — ограничений столько, что потом может быть очень больно что-то менять.

Відповісти

Підтримати

Андрей Литвинов

Андрей Литвинов C Señor 21.11.2019 15:51

Кассандра хороша, когда нужен быстрый доступ и масштабирование. Опыт все равно намного интереснее, чем с SQL. Но я с ней так плотно, как с MongoDB или EventStore не работал.

Відповісти

Підтримати

Konstantin Strukov

Konstantin Strukov 21.11.2019 15:58

Опыт все равно намного интереснее, чем с SQL

Как и любой новый опыт, полагаю. Просто потом новизна уходит, а проблемы нет :)

Відповісти

Підтримати

Андрей Литвинов

Андрей Литвинов C Señor 21.11.2019 16:00

Ок, кассандру вычеркиваем за недостатком опыта. MongoDB и EventStore?

Відповісти

Підтримати

Konstantin Strukov

Konstantin Strukov 21.11.2019 16:02

Ничего не могу сказать :) Монгу юзаю для пет проектов лет 7 или 8, никаких проблем — как один раз встало из коробки, так и живет (разве что на WiredTiger энжин переехал, как только завезли). Но поскольку нагрузки серьезной нет то и на грабли наступать негде. ИвентСтор — темный лес.

Відповісти

Підтримати

Андрей Литвинов

ТЗ 21.11.2019 21:40

Redis например быстрее Mongo
но это тоже ничего не занчит, зависит от задачи (и бюджета)

Но поскольку нагрузки серьезной нет то и на грабли наступать негде

вот

Відповісти

Підтримати

Konstantin Strukov

Dmitry Bugay 21.11.2019 23:33

Редис же не база а ин-мемори стор вроде.

Відповісти

Підтримати

ТЗ

Valeriy Shvets Engineer в Phonexa 22.11.2019 00:07

Это тоже хранилище, не реляционное, но персистентность есть и можно настроить чтоб оно хоть после каждого изменения сохраняло на диск (очень медленно и сомневаюсь что так кто-то делает).

Но лично я часто вообще отключаю персистентность и использую как чистый in-memory store для кешей и вспомогательных штук отличных от key-value: lists, sorted sets.

Если же говорить о логике в нём, то да, можно прямо в хранилище выполнять lua скрипты, вроде круто, но, redis однопоточный и пока крутится логика одного соединения — остальные ждут, как в nodejs при cpu bound нагрузке (если без worker’ов).

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

Відповісти

Підтримати

Dmitry Bugay

Андрей Литвинов C Señor 22.11.2019 00:30

я тут пишу крутую доменную логику, а что там происходит на уровне данных меня волновать не должно

Должно. Понимать как работает БД стоит на достаточно хорошем уровне. Схема данных и связанный с ней оверхед не должны мешать писать крутую доменую логику 🙂.

Відповісти

Підтримати

Valeriy Shvets

ТЗ 22.11.2019 01:09

ну вот.
на синтетическиз тестах и отдельных задачах редис хорош.
но то же может SQL Server
вопрос к задаче, архитектуре и конкретному архитектору

Відповісти

Підтримати

Valeriy Shvets

Valeriy Shvets Engineer в Phonexa 22.11.2019 07:19

отдельных задачах редис хорош

угу, он хорошо дополняет более традиционные решения.

Как говорил Лесь: «лєбєдь красівий, як лєбєдь, а обізяна, как обізяна» )

Відповісти

Підтримати

ТЗ

Dmitry Bugay 22.11.2019 11:31

как чистый in-memory store для кешей и вспомогательных штук

Так редис в 99% так и юзается.

Відповісти

Підтримати

Valeriy Shvets

Valeriy Shvets Engineer в Phonexa 22.11.2019 12:01

Возможно, статистики у меня нет.
Но по дефолту персистентность включена — делается снапшот в rdb файл. И от очень малого количества людей слышал чтоб они меняли дефолтный конфиг для отключения и что вообще там есть разные стратегии и настройки на этот счёт.

Відповісти

Підтримати

Dmitry Bugay

Bot Bot 22.11.2019 15:30

Everything’s a dildo if youre brave enough.

Відповісти

Підтримати

Dmitry Bugay

Alexander Merkulov asterisk guru 22.11.2019 11:15

Кассандра — фигня. Аероспайк используйте когда надо быстрый доступ. Кассандра доступ как раз не гарантирует(легко 0.5с может быть).

Відповісти

Підтримати

Андрей Литвинов

Dmytro Lapshyn Tech Lead в Fulcrum Rocks 02.12.2019 12:06

В этом плане ... EventStore идеальны

«Не-не-не, Дэвид Блейн!» ©

Участвовал я в одном проекте с event sourcing; так вот не было там бОльшей боли, чем изменение схемы event’ов.

Відповісти

Підтримати

Андрей Литвинов

Андрей Литвинов C Señor 02.12.2019 12:15

leanpub.com/esversioning

Відповісти

Підтримати

Dmytro Lapshyn

Dmytro Lapshyn Tech Lead в Fulcrum Rocks 02.12.2019 12:44

Версионирование событие было, само собой. Почти шесть лет спустя, я уже не вспомню всех подробностей, но что миграция уже сохранённых в event store событий, что перегенерация кода на основе изменившейся схемы событий таки неиллюзорно доставляли.

Відповісти

Підтримати

Андрей Литвинов

Андрей Литвинов C Señor 02.12.2019 12:46

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

миграция уже сохранённых в event store событий

перегенерация кода на основе изменившейся схемы событий

Звучат немного странно, но слышал, что некоторые так делают.

Відповісти

Підтримати

Dmytro Lapshyn

Андрей Литвинов C Señor 02.12.2019 12:16

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

Відповісти

Підтримати

Dmytro Lapshyn

Dmytro Lapshyn Tech Lead в Fulcrum Rocks 02.12.2019 12:52

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

У меня после того проекта сложилось ощущение, что event sourcing — это не для проектов, где требования меняются и дополняются на ходу.

Відповісти

Підтримати

Андрей Литвинов

Андрей Литвинов C Señor 02.12.2019 12:56

Наоборот, многие считают, что ES позволяют более гибко работать с изменяющимися требованиями. Нужно, конечно, конкретные кейсы рассматиривать, но если добавляется новое поле — не обязательно делать новую версию события и значительно менять логику. А если событие меняется существенно, возможно поменился какой-то концепт в домене, поменялось понимание и, возможно, это уже совсем новое событие с новым именем. Тогда и старые события в новые конвертировать не нужно.

Відповісти

Підтримати

Dmytro Lapshyn

Alexander Merkulov asterisk guru 22.11.2019 10:33

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

Відповісти

Підтримати

Konstantin Strukov

Dmitry Bugay 22.11.2019 11:32

Не знаю, как от сиквела может пригорать. Он логичен от и до.
Это же не js чтобы с него пригорать.

Відповісти

Підтримати

Alexander Merkulov

Left Outer Join 22.11.2019 13:46

Почему от него должно было пригорать?

Відповісти

Підтримати

Alexander Merkulov

Alexander Merkulov asterisk guru 22.11.2019 15:02

Да зайдите на основы БД в любой универ и послушайте.
Не должно. Просто необычно. А вы уже забыли как это необычно и вам уже нормально.

Відповісти

Підтримати

Left Outer Join

Left Outer Join 22.11.2019 15:18

Мне SQL всегда нравился

Відповісти

Підтримати

Alexander Merkulov

Bot Bot 22.11.2019 15:34

Единственное что мне не нравится когда там ничинают кучу бизнесс логики и всякие манипуляции со строками писать, тогда начинает черт знает что, а если юзать по назначению он отличный.

Відповісти

Підтримати

Left Outer Join

Sеrgеу Bоrуssenkо Senior Tractorist 22.11.2019 15:41

А мне больше всего не нравится, когда к SQL применяются все эти гибкие технологии разработки софта. В итоге «а давайте добавим это поле», а через неделю, а давайте сделаем его множественным, а потом а давайте добавим возможность иметь множество полей и т.д.
Именно поэтому всякие монги и стали популярны в стартапной среде, потому что SQL хорош только когда заранее четко обозначено ТЗ, которое можно разложить на модель базы, нормализовать ее, оптимизировать, прикинуть нужные индексы и подход к дальнейшему масштабированию.

Відповісти

Підтримати

Bot Bot

Andy W 22.11.2019 15:53

В итоге «а давайте добавим это поле», а через неделю, а давайте сделаем его множественным, а потом а давайте добавим возможность иметь множество полей и т.д.

за останні роки майже всі СУБД адаптувались до такого і додали тип даних JSON для таких речей

тобто, де треба фіксована структура — робимо таблички, поля, зовн ключі

а всі кастомні поля виносимо в JSON і граємось як хочемо

Відповісти

Підтримати

Sеrgеу Bоrуssenkо

Sеrgеу Bоrуssenkо Senior Tractorist 22.11.2019 17:48

Json не панацея, особенно если например нужны внешние ключи из других таблиц, например. Речь о том, что sql очень неповоротлива когда требования могут часто и радикально меняться. И требует больших усилий для изменений. Та даже такая простая штука как фича-бранчи — попробуй откатиться назад, когда схема базы уже изменилась. Нужно поддерживать обратные миграции, что делает процесс разработки ещё менее гибким

Відповісти

Підтримати

Andy W

Андрей Литвинов C Señor 22.11.2019 17:55

попробуй откатиться назад, когда схема базы уже изменилась

Для этого старые поля не удаляют и продолжают заполнять еще релиз-два, например. Оно так же актально и для БД, в которой нет схемы.

Відповісти

Підтримати

Sеrgеу Bоrуssenkо

anonymous 23.11.2019 21:40

-

Відповісти

Підтримати

Sеrgеу Bоrуssenkо

Konstantin Strukov 22.11.2019 15:41

Так это больше не про основы БД, а про качество отечественного образования — где top down подача не в чести исторически, и студиозусам сначала затрахают весь мозг формализмом, в итоге к тому моменту когда дело доходит до околоприкладных вещей пипл уже за деревьями леса не видит.

Відповісти

Підтримати

Alexander Merkulov

Vladimir Kovrigin Теоретик 04.12.2019 09:04

Это проблемы преподавания, а не сиквела

Відповісти

Підтримати

Alexander Merkulov

Alexandr Gavriluk .Net developer в Aspose 20.11.2019 00:32

8 лет уже пишу на C#, изредка на Java, за все время не написал ни одной строчки на SQL по работе.

Так что может быть от моего случая до того, что у вас будет в коде 70% SQL и 30% остального кода (кодокоментарии не считаем).

Відповісти

Підтримати

Vadim Koval 20.11.2019 09:19

Думал я один такой. За все время проработал в 3 конторах и нигде не было хотя бы 5% SQL, повезло же..

Відповісти

Підтримати

Alexandr Gavriluk

Vsevolod Iskrovsky dev 20.11.2019 17:15

смотря какие задачи ну и не сказать что повезло. если писать либы как Гаврилюк то да чистый компьютер сайенс уважаю, а так если орм пользовались значит сиквел на борту, но это поверхностный случай весьма

Відповісти

Підтримати

Vadim Koval

Marchello Lippi 20.11.2019 00:12

Не .NET + SQL Server в моєму випадку, але був в чомусь аналогічний проект Java + Oracle, на який мене покликали як дб дева. Отже, в двох словах — довелося розгрібати що понаписували джавісти без знання баз даних. На хвильку — логіка «на сторед процедурах в базі плюс простий виклик з джава аплікухи» відпрацьовувало в десятки разів швидше, ніж «все на джаві, тільки кінцевий результат записуємо в базу». Джавісти аргументували підхід тим, що так буде кросплатформенно, тобто встане на будь-яку базу (ну воно-то встане, тільки потім швидко ляже). Понаписували до мене стільки, що для мене вистачало на стабільний підробіток протягом декількох років(offtop_politota_begin), поки СЕО не самозашкварився, коли запросив поїхати в окупований Крим, після чого я припинив співпрацю зі свого боку(offtop_politota_end).

Відповісти

Підтримати

Dmitry Bugay 20.11.2019 13:56

На хвильку — логіка «на сторед процедурах в базі плюс простий виклик з джава аплікухи» відпрацьовувало в десятки разів швидше, ніж "все на джаві, тільки кінцевий результат записуємо в базу«

Ооо, сейчас нам расскажут о том, как правильно писать ентерпрайз.

Вангую, что через пару лет на ДОУ появится комент ноунейма в стиле «...позвали порефакторить старый монолит, потому что архитектура не позволяла развивать продукт дальше. Оказалось, что предыдущая команда написала все нормально, а потом позвали СУБД-джедая, который сломал всю архитектуру, вырубил топором половину бизнес-логики и запихнул ее в хранилки на PL-SQL, похожие на заклинания на древнегномских рунах, читая которые я вызывал сцотону раз в пару минут».

Відповісти

Підтримати

Marchello Lippi

Marchello Lippi 20.11.2019 16:03

предыдущая команда написала все нормально

Ага, нормально — поки кількість записів в базі вимірювалася десятками. Коли виросла до мільйонів, то користуватися стало неможливо. Тестування з заповненням dummy data, highload? Ні, не чули. Написав процедури, віддав — вирішуйте самі чи їх використовувати, на прод ставити прав не було. В результаті ще через пару років до мене зверталися за допомогою, однак (читати комент вище про політоту) вже більше з ними не хотів працювати.

Відповісти

Підтримати

Dmitry Bugay

Dmitry Bugay 20.11.2019 16:48

Ага, нормально — поки кількість записів в базі вимірювалася десятками.

Не утрируй. С десятками миллионов у меня например все ок. Без хранилок. Будут миллиарды — вот тогда приходи :)

Коли виросла до мільйонів...

Если вы «выросли до миллионов» — это не хайлоад. Это просто у вас появились хоть какие-то данные.

...то користуватися стало неможливо.

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

Подход «давайте запихнем логику в хранилки» большинством здравомыслящих людей рассматривается как зло.

Відповісти

Підтримати

Marchello Lippi

ТЗ 20.11.2019 17:14

Будут миллиарды — вот тогда приходи :)

хилый энтерпрайз

Відповісти

Підтримати

Dmitry Bugay

Dmitry Bugay 20.11.2019 17:19

Я честно, хотел сначала написать триллионы, но потом как-то постеснялся :)

Відповісти

Підтримати

ТЗ

Marchello Lippi 20.11.2019 18:00

Ок, в них були джавісти без якогось поняття в базах, крім елементарного. Прийшов я, 9y+ в базах, але з елементарним поняттям в джаві. Напевно СЕО повинен був шукати щось середнє, джавістів із знанням баз хоча би на рівні middle, а також найняти архітектора для цієї системи.

Подход «давайте запихнем логику в хранилки» большинством здравомыслящих людей рассматривается как зло.

Так як мене покликали пофіксити вузькі місця і я з цим справився, і після цього мені були готові давати замовлення далі, то вважаю що свою роботу я виконав, при тому що не вважаю свою позицію єдино вірною.
+ Так як я крім флуду і тролінгу намагаюся винести раціональне зерно, то поясніть свою позицію детальніше, будь ласка.

Відповісти

Підтримати

Dmitry Bugay

Dmitry Bugay 20.11.2019 18:16

то поясніть цю позицію детальніше, будь ласка.

Это старый холивар вокруг того, как разные специалисты видят базу. Писать логику внутри базы это любовь разных ДБА, которые хорошо умеют в T/PL-SQL но плохо или никак умеют в нормальные разные другие всякие языки программирования, которые, собственно и созданы для программирования. ДБА же хочет программировать на SQL, мотивируя это обычно «ну оно же в базе», «зато быстро».

Следование этому подходу приводит к тому, что на свет появляется малочитабельный, абсолютно непонятный никому кроме автора слой техномагии на неведомом языке, который делает нечто. В большинстве случаев после ухода ДБА этот слой или приходится сносить, или если снести совсем нельзя, то использовать как священные и необъяснимые технологии Древних.

Вот хороший пост, например
dou.ua/...ery-mysql-server/#1688338
И вообще тред хороший.

Відповісти

Підтримати

Marchello Lippi

Marchello Lippi 20.11.2019 18:53

на свет появляется малочитабельный, абсолютно непонятный никому кроме автора слой техномагии на неведомом языке

Чесно кажучи, очікував зважений комент, а тут просто річ у тому, що не вмієте чи не дуже вмієте в бази. Нечитабельним можна зробити будь-який код при бажанні.

холивар

Ок, під це визначення підходить ідеально.

Вот хороший пост, например
dou.ua/...ery-mysql-server/#1688338

Тут єдине раціональне зерно — що в mysql дійсно потрібно дропати і створювати процедуру для її зміни. Нижче солюшн — робити це через лоадбалансер, тобто спрямувати запити на інший сервер з потрібними змінами. Я не дуже вмію в джаву, та здогадуюся, якщо бізнес-вимоги не допускають даунтайм для зміни процедури, то і зміни в коді джави на ходу теж не ок. Тоді справа не в тому, де в нас вся логіка, а у вмінні писати читабельний код, читати чужий код, робити зміни в проді без даунтайму.

Відповісти

Підтримати

Dmitry Bugay

Dmitry Bugay 20.11.2019 22:10

Тут єдине раціональне зерно

Дальше даже продолжать не хочется. Пишите энтерпрайз внутри баз.
К меседж брокерам подключайтесь сиквелем, пишите ДДД абстракции на пл скл, вперед. Создавайте процессы параллельной обработки данных внутри хранилок, вебсервером тоже пусть бд будет.

Відповісти

Підтримати

Marchello Lippi

Andy W 20.11.2019 22:27

Дальше даже продолжать не хочется. Пишите энтерпрайз внутри баз.

ти образивсі? :)

К меседж брокерам подключайтесь сиквелем

кожен інструмент для свого діла

пишите ДДД абстракции

після цього якось не заходить про «слой техномагии на неведомом языке» і про «нормальні мови»

Создавайте процессы параллельной обработки данных внутри хранилок

вони для цього не призначені
а от зробити так, щоби сервер *сам* організував паралельну обробку даних — вже можливо, якщо конструкція сервера це передбачає взагалі

вебсервером тоже пусть бд будет

вона для цього не призначена, кожен інструмент .... (див вище)
але є, приміром, такі штуки — postgrest.org

Відповісти

Підтримати

Dmitry Bugay

Dmitry Bugay 20.11.2019 22:33

ти образивсі? :)

Нэ. Просто не хочу ломать копья.

вона для цього не призначена

База — хранилище.
Она вообще не предназначена для логики. Она предназначена для «сохрани» и «дай».

Відповісти

Підтримати

Andy W

Marchello Lippi 21.11.2019 00:00

не хочу ломать копья

Можна зашитися ментально в одному бізнес-кейсі і не хотіти знати інших кейсів. Якщо так спокійніше жити — будь ласка.

База — хранилище.
Она вообще не предназначена для логики. Она предназначена для «сохрани» и «дай».

Подам приклад. Є база даних з банківськими операціями. Всі дані в базі, сторонніх джерел нема. Логи авторизації в інтернет-банкінг також в базі. Є ціль — вичислити спроби фроду. Отже, ми беремо дані з бази, робимо певні обчислення і записуємо результати в цю ж базу. І тут питання: чи потрібні нам для обчислень якісь аплікухи, крім засобів самої бази? Джавіст скаже: обов’язково — бо хоче щоб таски падали на нього. Дб дев скаже: не потрібні — бо також хоче, щоб таски падали на нього.

Я не виключаю, що існують бізнес-кейси, коли без аплікухи ніяк. Однак коли ситуація така як описана вище, то питання лише в тому, хто архітектор рішення — джавіст чи дб дев, відповідно він під своє розуміння побудує стек і відповідно підбере команду.

Відповісти

Підтримати

Dmitry Bugay

Valeriy Shvets Engineer в Phonexa 21.11.2019 09:19

Решение с базой напрашивается как бы само собой, но количество таких фрод проверок растёт, нагрузка на базу по cpu растёт — масштабируем вертикально пока железка позволяет. Всё равно начинаем упираться, ok, давайте slave реплику, потом ещё одну. Если база взрослая то по лицензиям начинаем нормально платить. Для мастера каждая реплика тоже не бесплатно получается.

Имхо, главная проблема с логикой в базе — это масштабирование.

Відповісти

Підтримати

Marchello Lippi

ТЗ 21.11.2019 21:46

еще всякие инмемори тут всплывут
в сравнении с No-SQL (Mongo / Redis) разница будет в стоимости и предпочтениях разработчика

Відповісти

Підтримати

Valeriy Shvets

Dmitry Bugay 21.11.2019 23:34

Разница еще в схемах деплоя. Мы вот взяли хазлкаст. Он может работать без мастер-слейв схемы.

Відповісти

Підтримати

ТЗ

Dmitry Bugay 21.11.2019 11:31

Подам приклад.

Вы не понимаете, о чем вам говорят, и не хотите понимать. Что типично для фанатов логики в базе.

робимо певні обчислення і записуємо результати в цю ж базу.

А в рамках ентерпрайза это не важно. Завтра вам нужно будет записывать их не в эту, а другую базу. А после завтра — еще и в носкль базу. Тоже другую. А после-после завтра еще и в брокер отсылать. И на кой кому-то нужны ваши неуклюжие непортируемые скрипты, прибитые гвоздями к любимой субд?

Логи авторизації в інтернет-банкінг також в базі. Є ціль — вичислити спроби фроду.

Проблема понимания многих ДБА в том, что у вас свет клином сошелся на базе и данных, и вы ничего вокруг не видите. Ваша цель не только в факте вычисления попыток фрода, а в том, чтобы вычислить, и сделать процесс вычисления и результат, доступнымы, портируемыми и расширяемыми.
Они являются таковыми в любом нормальном приложении, но НЕ являются таковыми в базе.

І тут питання: чи потрібні нам для обчислень якісь аплікухи, крім засобів самої бази?

Да, нужны. Просто вы этого не понимаете.

Джавіст скаже: обов’язково — бо хоче щоб таски падали на нього.

Джавист ложил на таски. Джавист знает, что любая интерпрайз система обрастает с течением времени интеграциями. И еще джавист видел адовы поделия ДБА-гуру, которые пытаются имитировать нормальные интеграции какими-то сумасбродными велосипедами. Вместо человеческого меседж брокера начинаются темы «а давайте мы вам в табличку будем кидать, а вы ее читать раз в минуту».

Відповісти

Підтримати

Marchello Lippi

Олександр Мощенко 21.11.2019 12:20

+ 100500
Да и транзакции тоже не нужны. Бо сегодня у нас бд, а завтра сага на кафке, то зачем привязываться гвоздями к этому? Внешние ключи туда же, вдруг у нас сущности в разных шардах когда-то будут. Триггера вообще неконтроллируемое хтоническое нечно. Так что не паримся, берём майисам (скорость!), и реализуем всё нужное нам в коде. Ну, там, дозаполнить 1000 сущностей деталями — всего 1000 запросов в бд, херня для современной техники. Зато в будущем, когда мы поднимем 500 шардов и баллансировщик, все эти запросы выполнятся параллельно.

Відповісти

Підтримати

Dmitry Bugay

Андрей Литвинов C Señor 21.11.2019 13:04

Есть привкус сарказма почему-то, но мысли здравые.

Відповісти

Підтримати

Олександр Мощенко

Dmytro Lapshyn Tech Lead в Fulcrum Rocks 02.12.2019 12:35

Да и транзакции тоже не нужны. Бо сегодня у нас бд, а завтра сага на кафке, то зачем привязываться гвоздями к этому

Внезапно, даже в этом случае нужны :) только не распределённый two-phase commit, конечно:

microservices.io/...transactional-outbox.html

Відповісти

Підтримати

Олександр Мощенко

Дмитро 02.12.2019 16:53

transactional outbox это обычная acid транзакция в рсубд, причем оно к кафке или сагам? при моделировании бизнесс операции на кафке вообще нет необходимости делать описанное в этом подходе, да и не сделаешь это никак. Точное так же как и 2PС кафке не нужен.

Відповісти

Підтримати

Dmytro Lapshyn

Dmytro Lapshyn Tech Lead в Fulcrum Rocks 02.12.2019 17:43

При том, что эта транзакция по итогу гарантирует гарантированную доставку domain events, даже если микросервис упал после завершения транзакции, но до отправки доменного события в message broker

Відповісти

Підтримати

Дмитро

Дмитро 02.12.2019 18:01

При подходе, когда кафка хранит события, на которых моделируеться бизнесс операция, события отправленные в кафку и есть базой данный. там никто не пишет в еще одну базу данных что-то что надо писать атомарно вместе с ивентом.
Вот этот подход, transactional outbox используют там, где есть база данных на запись, кроме самих доменных ивентов. Дичь еще та — обычно такого надо поменьше делать. Transaction outbox вообще не для ивент сорсинга был придумал, а как описано что бы в транзакции поменять данные и отпаблишить на брокер событие другим получателям.

Відповісти

Підтримати

Dmytro Lapshyn

Dmytro Lapshyn Tech Lead в Fulcrum Rocks 02.12.2019 18:35

Если вы Кафку используете как event store, то да, в этом случае ни ACID, ни transactional outbox, конечно, не нужны.

Відповісти

Підтримати

Дмитро

Андрей Литвинов C Señor 02.12.2019 19:06

Только это очень плохая идея. Кафка, например, не умеет в optimistic concurrency. Да и как восстановить текущее состояние сущности по ивентам из Кафки? Или сущность будет eventually-consistent-на? Как тогда она будет гарантировать правильность принятия решений.

Відповісти

Підтримати

Дмитро

Дмитро 02.12.2019 22:05

Как тогда она будет гарантировать правильность принятия решений.

Если ты делаешь например систему по cqrs то write источник или event store не допустит разрушения агрегата за счет контроля его ревизии, в kafka же гарантии абсолютно аналогичны но подход другой, все конкуретные запросы пойдут в обработку и все эти запросы поступят например на сервис работы со складом — если на складе один айтем, его заберет первый, кто отправил запрос и получит ответ с подтверждением операции, все остальные получат из стрима сообщение о неудачном выполнении операции, если окажется что например payment service не даст тому что забрал со склада последний товар его оплатить из-за нехватки денег, прийдет отказ оплаты на сервис магазина , а он в свою очередь отправит ивент и вернет item на склад — (это и есть саги).
Поскольку в кафке есть транзакции на запись в том числе между стримами и гарантия exact once delivery + однопоточность и порядок доставки на consumers, где и содержится вся бизнес логика валидации — это дает такие же гарантии консистентости данных в distributed среде, как ты бы получил работая с рсубд и acid транзакциями. Единственное отличие асинхронность получения подтверждения, хотя учитывая возможности дизайна таких систем в большинстве случае они куда более realtime и имеют меньшую latency чем залоченные ресурсы в субд особенно под нагрузкой.

Відповісти

Підтримати

Андрей Литвинов

Андрей Литвинов C Señor 02.12.2019 22:11

Что-то я запутался. Давай сначала определимся откуда мы знаем, что остался один айтем на складе, если у нас нет БД.

А потом как мы обрабатываем два параллельных запроса на резервацию этого айтема.

У меня сложилось впечатление, что для того, чтобы это решить проблемму concurrency, команды на резервацию айтема будут выполняться только одним consumer-ом последовательно.

Відповісти

Підтримати

Дмитро

Дмитро 02.12.2019 22:25

Что-то я запутался. Давай сначала определимся откуда мы знаем, что остался один айтем на складе, если у нас нет БД.

Юзаешь kafka streams, что по id вернут состояние агрегата из соседнего стрима.
kafka.apache.org/...reams/kstream/KTable.html
KTable is an abstraction of a changelog stream from a primary-keyed table. Each record in this changelog stream is an update on the primary-keyed table with the record key as the primary key.
Должно вызывать правильные ассоциации :)

А потом как мы обрабатываем два параллельных запроса на резервацию этого айтема.
У меня сложилось впечатление, что для того, чтобы это решить проблемму concurrency, команды на резервацию айтема будут выполняться только одним consumer-ом последовательно.

Одним в рамках партиции. В кафке это ключевая концепция дизайна — в рамках consumer group каждая партиция работает однопоточно, но за счет того, что все партиции обрабатываются параллельно система скейлиться горизонтально и там не возникает concurrency.
почитай литературу, где описывают моделирование бизнесс операций на стримах, судя по всему ты не много сталкивался с kafka и делаешь выводы, о том где кафку нельзя юзать из дешевых блог статей на medium’e. Почитай литературу соответвующую, на гитхабе\лабе можно найти примеры систем на стримах. Вот, что стоит почитать по этой части:
Ben Stopford — designing event driven systems concepts and patterns for streaming Services with Apache Kafka

Відповісти

Підтримати

Андрей Литвинов

Андрей Литвинов C Señor 02.12.2019 22:52

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

Вообще, да KDB рулит. Make distributed monolith great again.

Відповісти

Підтримати

Дмитро

Дмитро 02.12.2019 23:10

И это должно как-то скейлиться? Или я что-то снова упускаю?

Все реактивные и real-time системы полагаются на аналогичные подходы — акторы, stream processing все real-time предполагает неконкурентную работу с данными в одном потоке :) так что я думаю, что вопрос скорее риторический.

Make distributed monolith great again

www.linkedin.com/...rchitecture-stefano-rocco

Один из самых правильных примеров микросервисов ‘по эвансу ‘ с инкапсуляцией доменных ивентов внутри микросервиса lose coupling в общении между микросервисами, и бизнесс операциями на конкурентных данных — с объяснением паттернов в статье приложен код. все на Kafka:)

Відповісти

Підтримати

Андрей Литвинов

Андрей Литвинов C Señor 02.12.2019 23:16

Понятно. Я думал, что я что-то важное пропустил. Актор — это аналог агрегата в DDD, тоже представляет собой границу транзакции, одну сущность. Если в кафке идти этим же путем — получится, что на каждую сущность нужно создавать отдельный топик. ES так умеет by design, в кафка — нет, она не сможет с таким подходом скейлиться достаточно хорошо. Поэтому там обычно пишут в один партишен все события всех агрегатов заданного типа. Но если это использвать как single source of truth и ksql, нужно будет все обрабатывать в одном потоке, что будет неверояно медленно. А параллельно процессить не получится, потому что кафка не умеет в optimistic concurrency. Но я это все на medium прочитал, так что можно серьезно не воспринимать.

Відповісти

Підтримати

Дмитро

Дмитро 02.12.2019 23:32

Поэтому там обычно пишут в один партишен все события всех агрегатов заданного типа

Это не есть партицирование :) поэтому все выводы заведомо ложные. Если тебе это правда интересно — почитай разберись попробуй прототип сделать и сделай выводы для себя. Партицирование, в том числе в Кафке работает так, что тип агрегата один, весь набор инстансов агрегата сегментируется и каждый сегмент процесится отдельно и параллельно. Веришь или нет, но на Кафке это делают только так и ни как иначе:)

Если в кафке идти этим же путем — получится, что на каждую сущность нужно создавать отдельный топик

Обычно делают один топик на микросервис можно и больше, надо смотреть по ситуации, главное что в Кафке есть транзакции на запись между топиками — так, что если надо записать в более чем один топик консистентно это ничего не мешает сделать и не требует велосипедов типа outbox .

Відповісти

Підтримати

Андрей Литвинов

Андрей Литвинов C Señor 02.12.2019 23:42

Да, я описывал топики. А сколько партишенов ты делаешь на топик? Какой уровень параллелизмами системе?

Відповісти

Підтримати

Дмитро

Дмитро 03.12.2019 00:23

Я не юзаю кафку. По аналогии с тем, что мы делаем — если бы была Кафка было бы от 100 до 1к партиций на топик(на машину не больше 200 партиций бы попадало) что бы делать наши типичные задачи(в основном вводы новых компонентов и перепрогонка стрима для просчета read данных).

Відповісти

Підтримати

Андрей Литвинов

Андрей Литвинов C Señor 03.12.2019 00:27

Ясно 🙂.

Відповісти

Підтримати

Дмитро

Андрей Литвинов C Señor 03.12.2019 00:40

На всякий случай, если кто-то еще читает, www.linkedin.com/...eded-maria-hatfield-phd/

For most implementations you want to follow the rule of thumb of 10 partitions per topic, and 10,000 partitions per Kafka cluster. Going beyond that amount can require additional monitoring and optimization.

100 до 1к партиций на топик

может быть очень дорого, хотя, для вашего юз-кейса может и норм. В любом случае, я бы так не делал.

Відповісти

Підтримати

Дмитро

Дмитро 03.12.2019 01:11

Это не проблема Кафки в нашему случае это медленные консьюмеры.

Відповісти

Підтримати

Андрей Литвинов

Андрей Литвинов C Señor 03.12.2019 08:15

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

Хотя, может, у меня просто пазлик не до конца сложился. Сага же будет читать из разных топиков и писать в разные партишены. Но если попробуешь — обязательно поделись опытом.

А для построение read-model-ей кафка подходит идеально, да, но саги тут ни при чем.

Відповісти

Підтримати

Дмитро

Дмитро 03.12.2019 08:53

Подводя черту, даже если такой подход будет работать в каком-то конкретном юз-кейcе, на сравнительно небольших обхемах данных или с медленными консьюмерами по сравнению со скоростью чтения данных

Вот nice use case — под твой случай как раз по поводу ложности таких выводов.
medium.com/...sing-platform-a3ee651812a

Delivery/Processing semantics: some use case is ok with losing some events in the pipeline, while other ones may require much higher durability guarantees. Some stateful streaming job also expects exactly-once processing guarantee where the computed states should always be consistent.

Job State: ranging from complete stateless parallel processing to jobs requiring 10s of TB large local states.

~500 billion events and ~1.3 PB per day
~8 million events and ~24 GB per second during peak hours

However, our story does not end here. We still have a long journey ahead of us to fulfill our platform vision
Microservices event sourcing architectural pattern

Зы: Но почему-то все читают это бредовую статью что Кафка не для ивент сорсинга вместо почитать тех блог нетфлткса.

Відповісти

Підтримати

Андрей Литвинов

Андрей Литвинов C Señor 03.12.2019 09:30

Ок, почитаю, на досуге. Ты говоришь делал какой-то PoC, есть где посмотреть?
Я бы с тобой порисовал у доски, мне лениво сейчас писать простыню разбора сейсов с concurrency. Как гарантировать, что сага не будет выполняться параллельно, если сообщения от сервисов ей будут приходить из разных партиций разных топиков с разными ключами. Пусть даже кафка гарантирует exactly once processing (не delivery).
Да и тот факт, что все внутренности всех сервисов будет доступны всем остальным сервиса, а не только публичные контракты. Это превратиться в месс очень бытро. Будет чудовищный распределенный монолит. Хз как такое можно рекомендовать в качестве хорошего архитектурного решения.

Відповісти

Підтримати

Дмитро

Дмитро 03.12.2019 09:43

Хз как такое можно рекомендовать в качесве хорошего архитектурного решения.

Просто ты видать не внимательно выше читал, вот отсыл к примеру с пояснением паттернов, когда доменные ивенты инкапсулированы внутри микросервиса, пример к тому же саги требущей строгой консистености — со схемами, кодом на кафке
dou.ua/...rums/topic/28953/#1729402
Я тебе также выше сбросил литературу по поводу волнующих тебя вопросов консистентности.
По поводу событий кокурентности разной природы:
— списание товара на складе
— отгрузка пользователю
если они идут потоком в одном топике с партицированием по productid то конкуретности нет. Сама сага работает с набором топиков — например из payment топика она может получить reject оплаты и сгенерировать событие в топик с которым работает склад. Консистентность достигаеться тем путем, что запись об ошибке в топик откуда получит ответ пользователь и роллебек в топик склада пишется в одной транзакции(что кафка умеет делать).

По поводу консистентности — предлагай сложные use cases, посмотрим насколько их сложно смоделировать с кафкой.

Відповісти

Підтримати

Андрей Литвинов

Андрей Литвинов C Señor 03.12.2019 09:46

Ок, думаю, будет смысл продолжить когда у тебя получится это дело покрутить в продакшене какое-то время.

Відповісти

Підтримати

Дмитро

Дмитро 03.12.2019 10:10

Я дал тебе ответы на твои вопросы в начальном риплае по поводу Кафки, ожидал честно говоря меньше высокомерия и больше конструктивизма по этому поводу.

Відповісти

Підтримати

Андрей Литвинов

Андрей Литвинов C Señor 03.12.2019 10:19

Ты конечно извини, но я отвечу тебе твоей же цитатой

судя по всему ты не много сталкивался с kafka и делаешь выводы, о том где кафку нельзя юзать из дешевых блог статей на medium’e

я сделаю выводы на счет высокомерия, не хотел, что бы это так казалось. Я пытался вывести дискуссию на очевидные пролемы, а ты предлагаешь их решать топиками и партишенами. Это как минимум будет выливаться в сложность развертываения и поддержки самой кафки.
Я допускаю, что можно изголиться и построить решение только на кфаке, но на сколько оно будет сложным в разработке деплойменте и поддержке? Рационально ли это?
Поэтому и говорю, что более предметно можно будет пообщаться, когда у тебя будет опыт спользования этого всего в продакшене.

Відповісти

Підтримати

Дмитро

Дмитро 03.12.2019 11:06

Ты конечно извини, но я отвечу тебе твоей же цитатой

ооок.., больше линки на документацию/литературу от вендора и отсылы к use cases типа нетфликс использовать не будут в дискуссия с тобой, правда думал это представляет для тебя какой-то авторитет.

Я пытался вывести дискуссию на очевидные пролемы, а ты предлагаешь их решать топиками и партишенами.

не я — а разработчики kafka.
я от тебя пока не услышал аргументов, на которых ты сделал выводы все свои, но услышал много негативного фидбека и оценочных суждений — у меня правда вызывает это удивление, тем более, что оно противоречит практике и теории использования технологии.
Я думал, что неприятие правда чем-то аргументировано — вижу что ни чем и мне этого достаточно.

Відповісти

Підтримати

Андрей Литвинов

Андрей Литвинов C Señor 03.12.2019 11:09

Дело в том, что я читал многие статьи и просмотривал книги, которые ты скидывал. Помино прочего, смотрел много их вебинаров и читал блог. Собственно, и аргументацию пытался приводить, но не получилось убедительно. Сложно убедить человека, который не готов слушать, я пока так не умею.

Відповісти

Підтримати

Дмитро

Дмитро 03.12.2019 11:28

у тебя слабая аргументация, если бы я согласился с ней — я бы слышал, а так я не слышу выходит?

Вот аргументы что обсуждались:
— kafka не имеет optmistic concurrency; как оказалось он и не нужен, что бы работать с консистентыми данными;
— как подтверждать бизнесс операции — однопоточная обработка данных + транзакции на запись между стримами, смотри Ben Stopford
— кафка экспоузит доменные ивенты ддругим сервисам, смотри пример с линкедина — integration events + snapshot propagation + event command mapping = loose coupling между сервисами, который к тому же на другом сервис брокере хрен сделаешь, где нет ордеринга.
— партицированная однопоточная обработка не скейлится — см use case netflix;
— kafka не может получить состояние агрегата по id, cм официальную доку;
— кафку будет сложно развертывать, сопровождать, если применить партицирование — читай официальную доку это единственно рекоммендуемым способ организовать скейлинг консьюмеров в кафке;

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

Відповісти

Підтримати

Андрей Литвинов

Андрей Литвинов C Señor 03.12.2019 11:39

kafka не имеет optmistic concurrency; как оказалось он и не нужен, что бы работать с консистентыми данными;

Приходит несколько http запросов на выполнение операции над сущностью, как ты будешь хендлить concurrency c kafka? Тебе придется все команды присать в какой-то топик и хендлить асинхронно. Можно, но зачем?

партицированная однопоточная обработка не скейлится — см use case netflix;

Я не говорил, что она не скейлится, я говорил, что если нужно при этом хендлить concurrency то скейлится она только добавление новых партишенов, что усложняет развертываение.

kafka не может получить состояние агрегата по id, cм официальную доку;

Для этого нужно использовать ksql, а не вычитвать события из стрима агрегата, как это делается в нормальных ES системах. Хз какие это проблемы добавляет, не работал с ksql.

кафку будет сложно развертывать сопровождать если применить партицирование — читай официальную доку это единственно рекоммендуемым способ организовать скейлинг консьюмеров в кафке;

Еще раз, у одной партции может быть много консьюмеров, не обязательно для этого плодить партиции, но при этом буду возникать проблемы с concurrency.

я допускаю что в чем-то заблуждаюсь

ok

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

Та мне лениво этим заниматься, я не ожидал, что это вырастет в такую длинную дискуссию, для себя выводы тоже сделаю. Я не ставил задачу тебя в чем-то переубедить. Попробуй заюзай эти подходы в проде.

Відповісти

Підтримати

Дмитро

Дмитро 03.12.2019 12:00

Еще раз, у одной партции может быть много консьюмеров, не обязательно для этого плодить партиции, но при этом буду возникать проблемы с concurrency.

насколько я знаю партиции плодить обязательно. в kafka можно сделать 1 партицию и добавить больше одной консьюмер группы — но тогда каждая такая группа подписчиков будет читать весь стрим по порядку. Балансировка и скейлинг в кафке делаеться только через партицирование.
То что ты предлагаешь по аналогии с ребитом — сделать exchange на него queue, а на очередь повесить кластер для балансировки обработки сообщений — нельзя, да и как ты себе это представляешь в системе, где каждый консьюмер коммитит offset прочтенных сообщений.

Відповісти

Підтримати

Андрей Литвинов

Андрей Литвинов C Señor 03.12.2019 12:02

Это пошли домыслы. Я не говорю, что партиции не нужны, я говорю, что не нужно делать их сотнями на топик.

Відповісти

Підтримати

Дмитро

Дмитро 03.12.2019 12:04

Я тебе говорю, что ты не можешь распаралелить чтение сообщений в кафке, если не отпартицируешь топик.

Еще раз, у одной партции может быть много консьюмеров, не обязательно для этого плодить партиции

так нельзя. где это прочитал?

Відповісти

Підтримати

Андрей Литвинов

Андрей Литвинов C Señor 03.12.2019 12:08

Похоже, ты сам уже запутался. Ладно давай сворачивать дискуссиию. Я соглашусь, кафку можно использовать как single source of truth, только нужно задумываться и понимать подводные камни. Так же понимать челленджи и альтернативы.

Відповісти

Підтримати

Дмитро

Дмитро 03.12.2019 12:13

Да не запутался я, просто ты пишешь то чего нет на самом деле.

svn.apache.org/...ite/082/introduction.html
Note however that there cannot be more consumer instances than partitions.

Відповісти

Підтримати

Андрей Литвинов

Андрей Литвинов C Señor 03.12.2019 12:21

Верно. Я имел в виду, что из одной партиции могут читать разные консьюмеры. Думаю, ты так же читал, что чем больше партиций, тем больше времени на рекавери и медленее репликация?

Відповісти

Підтримати

Дмитро

Дмитро 03.12.2019 12:25

Я имел в виду, что из одной партиции могут читать разные консьюмеры.

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

Відповісти

Підтримати

Андрей Литвинов

Андрей Литвинов C Señor 03.12.2019 12:24

Не, стоп, нифига, как на счет consumer groups?

Відповісти

Підтримати

Дмитро

Дмитро 03.12.2019 12:26

Не, стоп, нифига, как на счет consumer groups?

а что с ними? каждая группа читает топик от начала до конца, консьюмеров столько сколько партиций и каждый читает в одном потоке свою партицию — все. Добавишь консюмер группу, еще раз перечитаешь все сообщений от начала до конца. Consumer group — аналог queue в rabbit.

Відповісти

Підтримати

Андрей Литвинов

Андрей Литвинов C Señor 03.12.2019 12:28

Вот это и есть параллельная обработки сообщение не добавляя новых партиций постредством consumer groups. Я про этот кейс говорил выше. А ты говорил, что так нельзя.

Відповісти

Підтримати

Дмитро

Дмитро 03.12.2019 12:37

Добавление consumer group это просто введение нового подписчика. он читает стрим от начала до конца и не ускоряет работу уже существующей consumer группы :)
если у тебя есть 1 млн сообщений и тебе надо их отпроцессить каждая consumer group процесит их от начала до конца(в целом пр очитаешь 2 млн сообщений), а не параллелит между собой получение сообщений(то что ты ожидаешь что каждая прочитает по 0,5 млн.

Відповісти

Підтримати

Андрей Литвинов

Андрей Литвинов C Señor 03.12.2019 12:43

КЭП? Не обязательно процессить все сообщения, можно выбирать по тому же хешу ключа в разных консюмер группах, если нужно больше консьюмеров, чем партиций. Но зачем этим заниматься?

А если возвращаться к масштабированию, дабавление новой партиции тоже нетривиальная задача. Короче, для чего мы это обсуждаем? Если хочется жевать кактус с kafka как single source of truth — by all means. Туда же транзакции и exactly once delivery.

Відповісти

Підтримати

Дмитро

Дмитро 03.12.2019 12:49

Не обязательно процессить все сообщения, можно выбирать по тому же хешу ключа в разных консюмер группах, если нужно больше консюмеров, чем партиций. Но зачем этим заниматься?

Хеш ключа — это и есть тоже самое партицирование, от которого ты только, что предлагал отказаться и скейлиться добавлением паралеллельных консьюмеров на партицию, вместо увеличения количества партиций. :)
выглядит уже так что ты споришь ради поспорить, даже не понимая, что сам свою аргументацию предыдущую опровергаешь.

Відповісти

Підтримати

Андрей Литвинов

Андрей Литвинов C Señor 03.12.2019 12:52

Явкурсе. Я показал, как можно добавлять подписчиrов, не увеличивая количество партиций, когда ты сказал, что это невозможно. Я уже понял, что спорить тут бесполезно, третий раз пытаюсь спрыгнуть 🙂.

Відповісти

Підтримати

Дмитро

Дмитро 03.12.2019 12:58

Я показал, как можно добавлять подписчиrов, не увеличивая количество партиций, когда ты сказал, что это невозможно

Не показал.
мы сначала говорили о партицировании внутри консьюмер групп, ты предложил отпартицировать консьюмер группы. что так что так партицирование.

Добавить паралельную обработку партиции несколькими консьюмерами без партицирования пока не обьяснил как. :)
по поводу предложенного подхода — это велосипед, не рекоммендованный само собой вендором. Давай говорить в такой плоскости.

зы: вообще лишенный смысла разговор реально, уровень дискуссии крайне низкий в плане технологий и подходов, я пожалуй тоже сольюсь.

Відповісти

Підтримати

Андрей Литвинов

Андрей Литвинов C Señor 03.12.2019 13:04

Давай на пальцах и закончим на этом. Есть один топик и один партишен. Нужно два параллельных консьюмера. Запускаем два консьюмера в разных группах.
В первом делаем if (message.key) % 2 == 0 process(message) else return.
Во втором делаем if (message.key) % 2 == 1 process(message) else return.

Відповісти

Підтримати

Дмитро

Дмитро 03.12.2019 13:06

я понял твой подход меня только удивляет, что ты споришь со мной и противоставляешь его партицированию топика :) что это как не партицирование? :)

Відповісти

Підтримати

Андрей Литвинов

Андрей Литвинов C Señor 03.12.2019 13:09

Я писал о том, что множество физический партиций заметляют recovery, добавляют latency в репликацию и усложняют поддержку этого всего.

что это как не партицирование?

Я наивно полагал, что под партиционированием мы оба понимаем физицеское партиционирование внутри топика.
Фсе, больше на этот тред отвечать не буду. Спасибо за интересную дискуссию и сслыку на блог нетфликса — почитаю на досуге.

Відповісти

Підтримати

Дмитро

Андрей Литвинов C Señor 03.12.2019 15:16

я допускаю что в чем-то заблуждаюсь

Все таки решил продумать юз-кейс с concurrency и partition key, потому как изначально показалось разумным вариантом.

Представь, что есть сага. Она отпраляет команды с partition key id аггрегата. Те, кому она команды отправляет обрабатывают их без проблем и отправляют ей назад ивенты. Что использовать в качестве partition key для ивентов в этом случае? Если id аггрегата, как это обычно делают, то разные ивенты к одной саге будут обрабатываться ранзными консьюмерами. Будет проблема.

Выходом может быть указание partition key ивента id саги, но тогда по ивентам нельзя будет все ивенты агрегата обрабатывать в хронологическом порядке в рамках одного подписчика, так как они будут попадать в разные партиции. Понятна проблема?

Другим решением может быть подписка на ивенты агрегата и генерация на их основании других ивентов с partition id саги, но нужно будет добавлять еще одного consumer-а и дублирвать эти ивенты. И протягивать id саги через всю эту логику. Тоже неидеально, но может быть рабочим вариантом.

При этом, в отличии от Actor Model, consumer будет обрабатывать сообщение группы аггрегатов внутри партиции по-очереди, что может вызывать дополнительную latency.

Вобщем, как-то так. Надеюсь у меня получилось обрисовать проблемы токого подхода, без понимания которых нужно будет знатно выгребать в продакшене. И это только организация работы c concurrency, не затрагивая остальные вопросы. И без учета изменения количества партиций.

Відповісти

Підтримати

Дмитро

Дмитро 03.12.2019 21:34

Представь, что есть сага. Она отпраляет команды с partition key id аггрегата. Те, кому она команды отправляет обрабатывают их без проблем и отправляют ей назад ивенты. Что использовать в качестве partition key для ивентов в этом случае? Если id аггрегата, как это обычно делают, то разные ивенты к одной саге будут обрабатываться ранзными консьюмерами. Будет проблема.

проблемы не будет потому, что используеться не orchestration based, a choreography based saga.
Пример моделируем 3 компонента процесят ивенты —

Payment topic (partition by account id) в него пишет OrderService, когда оплаичиваем заказы
Order topic (partition order id) в него пишет PaymentService, StockService, когда меняем статус заказа.
Stock topic (partition by product id) в него пишет Order Service когда резервируем товар

конкуренция возникает в следующих ситуация соотвественно —
Payment service — пытаемся оплатить два и больше ордера с одного аккаунта(поскольку партицирование по account id с одним аккаунтом работает только один consumer)
Order service — юзер пытается с разных девайсов один и тот же ордер оплатить и отредактировать или разные сервиса меняют статус заказа (поскольку партицирование по order id с одним заказом работает только один consumer)
Stock service — разные ордеры пытаються забрать один и тот же товар
(поскольку партицирование по product id с одним товаром на складе работает только один consumer)

Во всех случаях с одним и тем же Account/Order/Stock Item работает всего один поток. и запросы на их модификацию процесятся последовательно. если на каком-то из этапов тебе упадет ошибка максимум, что тебе надо будет, послать событие отмены на 1 или больше получателей(в разные топики), что бы была консистентность событие на обработку во все топики запишется транзакционно, если консьюмер упал, зайдет ретрай(все или ничего с первого или второго раза).

Вот как это выглядит схематически — может поможет визуализация.
imgur.com/a/rpWLbO3

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

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

Відповісти

Підтримати

Андрей Литвинов

Андрей Литвинов C Señor 03.12.2019 21:38

Ох, ежик, попробуй на листике нарисуй что там будет происходить. Ладно, я попыталася.

Відповісти

Підтримати

Дмитро

Дмитро 03.12.2019 21:56

судя по кол-ву вакансий даже тут в разделе работа, где надо работать с data pipelines и Kafka(что в общем-то и есть то о чем мы дискутируем) то это не rocket science. Даже у нас не много менее востребовано чем весь дотнет со своим Энтерпрайзом и ‘романами на сиквеле’:)

Відповісти

Підтримати

Андрей Литвинов

andriy dmytrenko IT Geek 02.12.2019 19:45

ДБА же хочет программировать ...

ДБА — це не про «программировать».
ДБА — це «знов сіньори понаписували джойни та фільтри на стороні бекенду, замість SQL, валідують дані у себе в коді, замість впровадити констрейнти, а ти їм винь да положь адекватний перформанс та консистетність даних». Сам таке бачив.

Відповісти

Підтримати

Dmitry Bugay

Bot Bot 02.12.2019 21:54

валідують дані у себе в коді, замість впровадити констрейнти

Вот чем чем, а валидацией сиквел точно не должен заниматься, сиквел должен вернуть данные или получить данные и разложить по таблицам. Валидация это в большинстве случаев даже не бизнес логика, а UI левел.

Відповісти

Підтримати

andriy dmytrenko

anonymous 02.12.2019 22:48

-

Відповісти

Підтримати

Bot Bot

Bot Bot 03.12.2019 09:09

Але ту ж саму унікальність

проверяет банальный селект, не обязательно пихать в базу всю дичь подряд и потом ждать ошибку из нее.

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

В общем, Димон был прав коментом выше — у DBA часто sql головного мозга.

Відповісти

Підтримати

anonymous

Олександр Мощенко 03.12.2019 09:16

карочі ясно. замість констрейнту ми напишемо селект (фор апдейт, звісно, щоб ніхто не вліз поперед нас), зробимо це максимально читаємим, покриємо все це тестами, матимемо на увазі в процесі розробки що унікальність тут може бути не унікальна, бо тести застарівають.
В общєм ясно — для погромістів люба дічь, достатньо покрита тестами, перетворюється в крутон.

Відповісти

Підтримати

Bot Bot

Bot Bot 03.12.2019 12:22

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

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

Второе — ты предлагаешь ловить эксепшены и выдвать ошибку, я предлагаю сделать обычный селкет(ну нам же все равно открывать коннекшен в базу, хоть так хоть так) и никаких try catch с типизированными сиквельными ошибками (на самом деле он есть, но чтобы ловить факап приложения), мой вариант куда более здоровый потому как код отобразажет логику явно, а не в виде типизированных ошибко с try catch.

Есть метод который валидирует, а есть метод которых сохраняет уже отвалидированные данные. Как видишь мухи от колет отделены, открыл код и сразу ясно что и зачем.

try catch создается чтобы ловить факапы в поведении приложения, а не отображать бизенс логику.

для погромістів люба дічь, достатньо покрита тестами, перетворюється в крутон

Приложение без тестов это крутон? Ну для крудов и формошлепства кончено изилшества, для больших приложений маст хэв и серьезно упрощают разработку и супорт.

Відповісти

Підтримати

Олександр Мощенко

Олександр Мощенко 03.12.2019 12:40

я пишу о том, что помимо валидации «высокоуровневых» правил есть ещё валидация условий, при которых данные остаются консистентными. Связи по внешним ключам, какие-то базовые логические условности. Реализация этих проверок в бд не размазывает бизнес логику, а гарантирует относительную целостность данных. это просто другой уровень валидации. Иногда его можно совместить с валидацией в приложении, иногда не сто́ит. Ведь говоря про набор данных мы имеем ввиду не только то, что может быть, но и то, чего быть не должно.
И если уж за хранение данных у нас отвечает рсубд, то пусть уж она отвечает по максимуму за правильность хранимых данных. это отнюдь не отменяет валидацию в логике приложения но обезопасивает данные от ошибок приложения

Ну а про зашквары я не копенгаген, сорян. Програміровать по-понятіям нє умєю

Відповісти

Підтримати

Bot Bot

Bot Bot 03.12.2019 14:22

Об этом ты только сейчас написал, выше ты писал про крутоны. Перечитай свой меседж выше.

Відповісти

Підтримати

Олександр Мощенко

Олександр Мощенко 03.12.2019 14:33

частично согласен с претензией. С другой стороны я никогда не применял квантор, заявляя про «скл говолного мозга» или «вынос бизнес логики в бд» при любом умопинании триггеров, хранимок и констрейнтов. В разных ветках топика не раз и не два звучала мысль, что данные иногда стоит отделять от логики и работать с ними как с данными. Но если в этой ветке сия мысль не звучала, то твоя претензия справедлива.

Відповісти

Підтримати

Bot Bot

Serhii 03.12.2019 14:21

проверяет банальный селект, не обязательно пихать в базу всю дичь подряд и потом ждать ошибку из нее.

Так делать неправильно, т.к. увеличивается время жизни транзакции и понижается производительность.

Відповісти

Підтримати

Bot Bot

Oleksandr Katykhin 03.12.2019 21:58

Це типу васян і колян наповнюють (наприклад) довідник товарів. Васян в своїй сесії перевірив що товару «хрін» нема, і колян теж, обидва додають кожен по хріну. Десь так, да?

Відповісти

Підтримати

Bot Bot

Marchello Lippi 02.12.2019 21:58

При спробі валідації даних за допомогою констрейнтів «as is» юзер отримає не юзер-френдлі помилку. Звісно, можна перехоплювати помилки і видавати замість них більш зрозумілий текст.

Відповісти

Підтримати

andriy dmytrenko

Bot Bot 02.12.2019 22:03

Зачем ловить ошибки из сиквела если эти ошибки можно валидировать еще на уровне UI?

Відповісти

Підтримати

Marchello Lippi

Marchello Lippi 02.12.2019 22:14

Наприклад, якщо база наповнюється не лише з UI.

Відповісти

Підтримати

Bot Bot

Dmitry Bugay 02.12.2019 23:02

А это вы уже заложили себе проблему в архитектуру. Сели на порохвую бочку и покуриваете сигару.

Відповісти

Підтримати

Marchello Lippi

andriy dmytrenko IT Geek 03.12.2019 09:02

Наповнення бази з інших джерел, окрім UI — це порохова діжка, я правильно зрозумів вашу тезу?

Відповісти

Підтримати

Dmitry Bugay

Bot Bot 03.12.2019 09:16

Делается сервер, он содержит бизнесс логику с тестами, в итоге UI собирает инфу от юзера, отправляет на сервер, сервер решает что с ней делать потому что там бизнес логика, а база только содержит данные.

Это еще в универе показывали такую картинку — UI, логика и данные. Не надо скрещивать бульдога с носорогом.

Типа такой.
bourabai.kz/dbt/client/6_100000.gif

Відповісти

Підтримати

andriy dmytrenko

Marchello Lippi 03.12.2019 13:14

Тобто варіанти з наповнення бази одночасно через UI i API — це некошерно. Ну ок.

Відповісти

Підтримати

Dmitry Bugay

Dmitry Bugay 06.12.2019 11:16

Если схема такая:
UI —> DB <— API
То да, некошерно.

А должно быть:
UI —> API —> DB <— API

Відповісти

Підтримати

Marchello Lippi

Andy W 06.12.2019 12:18

UI —> DB <— API

а как ето?

Відповісти

Підтримати

Dmitry Bugay

Dmitry Bugay 06.12.2019 12:22

а как ето?

наповнення бази одночасно через UI i API

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

В данном случае у оратора есть два процесса:
UI —> DB, т.е. любая мордочка, которая пишет сразу прямо в базу, и
API —> DB, т.е. какоето рестоподобное апи, которое тоже пишет сразу прямо в базу.

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

Відповісти

Підтримати

Andy W

Александр Шевченко 07.12.2019 10:20

Если почитать ветку, оратор говорил, что нельзя вынести всю валидацию на UI так, как информация может приходить так же и через API(rest, soap, fix и т.д.). И эту информацию так же необходимо валидировать.

Відповісти

Підтримати

Dmitry Bugay

Андрей Литвинов C Señor 07.12.2019 11:38

UI вообще доверять нельзя и все нужно валидитьвать в API уровне входящих данных и бизнес правил. Но никак не в БД.

Відповісти

Підтримати

Александр Шевченко

Александр Шевченко 07.12.2019 12:12

БД не должна заниматься валидацией, но если в бизнес логике заложена уникальность чего-то то это должно быть отображено при проектировании базы. По крайней мере для реляционных.

Відповісти

Підтримати

Андрей Литвинов

Андрей Литвинов C Señor 07.12.2019 12:14

Я бы только слово «должно» заменил на «может». В некоторых случаях это проще решить с помощью БД, но совсем не обязательно.

Відповісти

Підтримати

Александр Шевченко

anonymous 07.12.2019 13:44

-

Відповісти

Підтримати

Александр Шевченко

Александр Шевченко 07.12.2019 14:30

Переносить в специально созданную таблицу, и уникальность не трогать? )

Відповісти

Підтримати

anonymous

anonymous 07.12.2019 18:53

-

Відповісти

Підтримати

Александр Шевченко

Sеrgеу Bоrуssenkо Senior Tractorist 07.12.2019 20:09

А потом когда нужно выполнить поиск вместе е с удалёнными элементами, то делать два запроса и мерджить в порядке сортировки? Или писать кучерявые запросы с километровыми джоинами?

Відповісти

Підтримати

Александр Шевченко

Andy W 07.12.2019 20:21

додати нулябельне поле «is_active» і зробити унікальність по двох полях

Відповісти

Підтримати

anonymous

Dmitry Bugay 02.12.2019 23:10

Дополню мыслю. Если вы пошарите базу между разными приложениями — вы рискуете расстрелять себе ноги из пулемета, потому что разные приложения это как разные домены логики. Даже если их сначала начинала писать ваша команда, и все было заебок, завтра одно из приложений может уехать другим разрабам, и у вас пойдет конкуренция за базу — вы ВНЕЗАПНО увидите констрейнт там, где он не нужен, или узнаете, что ваша новая структура данных на «той» стороне вычитывается не так, как было вами задумано.

Начнется взаимоотношения между командами типа:
Пидарасы <—> база <—> Пидарасы

Відповісти

Підтримати

Marchello Lippi

Андрей Литвинов C Señor 02.12.2019 23:18

Пидарасы <—> база <—> Пидарасы

Лол 😂

Відповісти

Підтримати

Dmitry Bugay

Олександр Мощенко 03.12.2019 09:03

Даже если их сначала начинала писать ваша команда, и все было заебок, завтра одно из приложений может уехать другим разрабам, и у вас пойдет конкуренция за базу

Даже если одно из приложений не уехало к другим разрабам, вы ВНЕЗАПНО увидите констрейнт не там. Просто потому что несколько человек все выходные быстро вкручивали функционал. для взаимоотношения пидарасов база, внезапно, не нужна вовсе)

Відповісти

Підтримати

Dmitry Bugay

Dmitry Bugay 06.12.2019 12:25

вы ВНЕЗАПНО увидите констрейнт

несколько человек все выходные быстро вкручивали

Да, организация труда у вас на уровне просто космос.
Сидит себе команда, делает проект, в пятницу ушли, в понедельник пришли, а там вкручено.
Просто часть ребят решили, что нужно вкрутить.

Відповісти

Підтримати

Олександр Мощенко

Олександр Мощенко 06.12.2019 12:34

Нет, просто один человек решил, что часть ребят решили что нужно вкрутить. Сам то он всегда всё делает как надо.

Відповісти

Підтримати

Dmitry Bugay

Dmitry Bugay 06.12.2019 12:58

Нет, просто один человек решил, что часть ребят решили что нужно вкрутить.

Это какая-то новая методика разработки. Разработка вслепую командой анонимусов, которые не знают, что над этим приложением работают другие анонимусы.

Відповісти

Підтримати

Олександр Мощенко

Oleksandr Nogai 06.12.2019 12:34

если вместо «база» поставить «API слой» то схема отношений изменится не очень сильно

тем не менее, проблема «больше одного API» существует — но на уровне конситентности данных. когда казалось бы одну и ту же сущность две команды создают и обновляют по разному

Відповісти

Підтримати

Dmitry Bugay

Андрей Литвинов C Señor 06.12.2019 12:38

если вместо «база» поставить «API слой» то схема отношений изменится не очень сильно

Но приниципиально, потому что владельцем этого API будет только одна из команд.

Відповісти

Підтримати

Oleksandr Nogai

Dmitry Bugay 06.12.2019 12:43

если вместо «база» поставить «API слой» то схема отношений изменится не очень сильно

Изменится, причем принципиально.

Апи не является хранилищем. Поэтому в случае
пидарасы <—> апи <—> пидарасы
База остается недоступной напрямую, и нету конкуренции разных логик за структуры данных.

тем не менее, проблема «больше одного API» существует — но на уровне конситентности данных. когда казалось бы одну и ту же сущность две команды создают и обновляют по разному

Так я тут как бы о том и речь веду, что так делать не надо.

Відповісти

Підтримати

Oleksandr Nogai

Sеrgеу Bоrуssenkо Senior Tractorist 07.12.2019 20:12

На уровне UI валидации не бывает, это не валидация, а скорее UX — коммуникация с юзером чего нам от него нужно. Валидация это всегда бизнес- логика, и должна делаться именно на этом слое

Відповісти

Підтримати

Bot Bot

Андрей Литвинов C Señor 07.12.2019 20:30

Валидация это всегда бизнес- логика

Не совсем. Валидация входящих данных, что дата — это дата, число — это число, имейл — это имейл или еще какие-то тривиальные вещи это еще не бизнес логика.

Відповісти

Підтримати

Sеrgеу Bоrуssenkо

Sеrgеу Bоrуssenkо Senior Tractorist 07.12.2019 21:04

Согласен. Просто в этом плане и в базе тоже происходит валидация — например максимальная длина текстового поля, или что дата в запросе это дата. Мне казалось, тут речь немного про другого рода валидацию шла.

Відповісти

Підтримати

Андрей Литвинов

Андрей Литвинов C Señor 07.12.2019 21:06

Да, там явно бизнес правило про дату начала и окончания какого-то события.

Відповісти

Підтримати

Sеrgеу Bоrуssenkо

Sеrgеу Bоrуssenkо Senior Tractorist 07.12.2019 21:12

На уровне UI тоже можно послать колбек на сервис и проверить соответствие бизнес- логике, чтобы сделать подсказку юзеру и все такое. Вопрос именно в том, что никто не гарантирует что когда введенные на клиенте данные придут на сервер они все ещё будут валидны. Это помимо того что сервер вообще не особо то должен быть в курсе какие клиенты и какая там у них валидация.

Відповісти

Підтримати

Андрей Литвинов

Dmitry Bugay 02.12.2019 23:04

валідують дані у себе в коді

Все, что не относится к юник констрейнтам — и нужно валидировать в коде.

замість впровадити констрейнти

Так и запишем — кандидат хочет писать бизнес-логику на стороне базы.

а ти їм винь да положь адекватний перформанс

У адекватных синьоров — адекватный перформанс.
А если перформанс неадекватный — то это такой синьор.

Відповісти

Підтримати

andriy dmytrenko

Олександр Мощенко 03.12.2019 09:01

Так и запишем — кандидат хочет писать бизнес-логику на стороне базы.

событие должно заканчиваться не раньше, чем начинаться — это бизнес логика, или ограничение на уровне данных? Или проверка что одно из необязательных полей должно быть заполнено, иначе эти данные не имеют смысла? Канешно проверять это на уровне приложения сто́ит тоже, но в приложении могут быть (и будут) баги и данные могут быть подпорчены.
Констрейнты — это не про валидацию данных на уровне приложения, это про валидацию на уровне самих данных.
Конечно в процессе какие-то вещи, казавшиеся незыблемыми раньше, меняются. В этом случае меняются проверки в бд. Это норма (ц).

Відповісти

Підтримати

Dmitry Bugay

Konstantin Strukov 03.12.2019 10:45

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

Вот это щас внезапно было.

Відповісти

Підтримати

Олександр Мощенко

Олександр Мощенко 03.12.2019 11:02

например логоподобная таблица в которую пишутся изменения из нескольких таблиц. table1_id, table2_id, table3_id — нулябельные поля, внешние ключи соотв. таблиц. Одно из полей должно быть заполнено.
Без связи эта запись — просто мусор.

Відповісти

Підтримати

Konstantin Strukov

Dmitry Bugay 06.12.2019 11:21

событие должно заканчиваться не раньше, чем начинаться — это бизнес логика, или ограничение на уровне данных?

Чо? Не только лишь все могут понять это вчера так же как сегодня.

Відповісти

Підтримати

Олександр Мощенко

Олександр Мощенко 06.12.2019 11:22

вот она, нищета природничо-математичної освіти.

Відповісти

Підтримати

Dmitry Bugay

Dmitry Bugay 06.12.2019 11:27

Ага. У вас она на высоком уровне, моделируете разрывы пространственно-временного континуума. Валидируете факт что прошлое не началось в будущем.

Відповісти

Підтримати

Олександр Мощенко

Олександр Мощенко 06.12.2019 11:34

внезапно кодеры кодят код. А юзеры заполняют поля. И в бд, внезапно, может прилететь всякое, не отфильтрованное. Это бывает, поверь.

Відповісти

Підтримати

Dmitry Bugay

Dmitry Bugay 06.12.2019 12:08

И в бд, внезапно, может прилететь всякое, не отфильтрованное.

Если архитектура через жопу, то конечно бывает.
Ну так не пишите архитектуру через жопу.

Если любой левый хрен в вашей системе может набросить вам данные прямо в базу — вы сами себе смешные буратины. Пишите больше ентерпрайза — потом нормальным пряморуким хлопцам будут платить большие деньги, чтобы переделать все как надо.

Это бывает, поверь.

Да зачем верить, я по вашим комментам и так понимаю, что у вас это норма :)

Відповісти

Підтримати

Олександр Мощенко

Олександр Мощенко 06.12.2019 12:31

вай вай вай, ідєальная машишева в тредє.

Из того, с чем столкнулся я: — на фронте юзается календарик (сторонний), позволяющий мышкой выбрать временно́й промежуток. Всё красиво, всё сохраняется и работает, битые даты валидируются и не сохраняются. А вот если мышкой выделить промежуток в обратном направлении (от конца до начала), то в одном из мест новое событие не отображается.
Конечно можно много «фу» сказать — как тестили, зачем сторонний календарь пользовали, почему интервал в разных местах кода проверятеся по разному и т.д. Но факт остаётся фактом — по недосмотру/тупости/етц. кодера и фантазии пользователя в бд записался временно́й парадокс. Которого можно было бы избежать, настроив констрейнт (на тот момент используемая версия мускуля не умела в констрейнты).
Вот про такое я и говорю — если зафиксировать схему данных, обмазать её проверками, то можно в некоторой степени обезопаситься от ошибок в коде. И эти проверки — не бизнес логика, а логика самих данных.

Відповісти

Підтримати

Dmitry Bugay

Dmitry Bugay 06.12.2019 12:47

записался временно́й парадокс.

Нет. Данная ошибка не по

недосмотру/тупости/етц. кодера и фантазии пользователя в бд

А потому что архитектор такое решения — криворук и его нужно гнать ссаными тряпками.
Привязывать уай напрямую к инсертам в базу — это уровень лабораторных на первом курсе, или победителей районной олимпиады по хатыэмэл за 9й класс.

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

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

Відповісти

Підтримати

Олександр Мощенко

Олександр Мощенко 06.12.2019 12:52

ще раз — данные были провалидированы. Даты — действительно даты, duration в разрешённых пределах, дата начала — в будущем.
Всё как положено. Кроме отсутствия проверки на инверсию.
НУ и да, мы скатились с обсуждения факта существования независимых от кода свойств данных в обсуждение крворукости/ссаных тряпок. Я это продолжать не буду.

Відповісти

Підтримати

Dmitry Bugay

Dmitry Bugay 06.12.2019 13:04

ще раз — данные были провалидированы.

Ще раз — вы построили изначально косячную архитектуру, которая позволила пихать в вашу базу говноданные.
И этот постыдный пример вы используете как иллюстрацию необходимости наворчивать в базе костыли, вместо того, чтобы признать необходимость нормальной архитектуры, а не уровня универовского поделия.

Відповісти

Підтримати

Олександр Мощенко

Олександр Мощенко 06.12.2019 13:09

Ну так расскажи нам болезным, как правильно сохранить две даты? Если последовательность валидация — сохранение это косячная архитектура, то что тогда не косячная?

Відповісти

Підтримати

Dmitry Bugay

Serhii 06.12.2019 12:10

А что удивительного в ошибочном вводе даты конца события?

Відповісти

Підтримати

Dmitry Bugay

Dmitry Bugay 06.12.2019 12:31

Удивительна сама постановка вопроса.

Хотя тут пожалуй, нужно уточнить. В моем понимании событие — это технологические данные, которые порождаются , а не юзер.

Например.

createEvent(userData) {
    Event e = new Event();
    e.created(now());
    e.setData(userData);
    ...processing...
    e.finished(now());
}

В таком случае event.created и event.finished не нуждаются в какой-то особенной валидации, поскольку не доступны для заполнения разным кожанным мешкам.

Если ты под ивентом понимаешь полностью юзер-драйвен данные, где он именно тыцает пальчиками начало и конец — то конечно нужна валидация.

Відповісти

Підтримати

Serhii

Dmytro Lapshyn Tech Lead в Fulcrum Rocks 06.12.2019 14:30

Если ты под ивентом понимаешь полностью юзер-драйвен данные, где он именно тыцает пальчиками начало и конец — то конечно нужна валидация.

Ну так Олександр именно об этом. Код валидации в слое бизнес-логики не проверял условие «дата окончания обязательно должна быть позже даты начала», видимо, потому, что полагались на то, что сторонний календарь просто не даст выбрать такую комбинацию.

С другой стороны, дублировать такую валидацию в базе — плохой фэн-шуй, так как это прямое нарушение DRY.

Відповісти

Підтримати

Dmitry Bugay

Andy W 06.12.2019 15:05

С другой стороны, дублировать такую валидацию в базе — плохой фэн-шуй, так как это прямое нарушение DRY.

Така перевірка має бути у API не залежно від того, де це API знаходиться — в окремій програмі чи у БД.
Перевірка «в календаріку» — це приємне юзабіліті доповнення і (я зараз фантазую) можна було б придумати спосіб, щоби частину таких перевірок прокидати з API в UI — якщо ми не пишемо ці штуки руками, то думаю, DRY на нас не сильно образиться.

Відповісти

Підтримати

Dmytro Lapshyn

Dmitry Bugay 06.12.2019 15:39

Код валидации в слое бизнес-логики не проверял условие ...потому, что полагались на ... сторонний календарь

Суть этой фразы.
Это говорит только о криворукости авторов системы.
Олександр выводит из этого попытку обосновать написание бизнес-логики на стороне базы.

Відповісти

Підтримати

Dmytro Lapshyn

Олександр Мощенко 06.12.2019 15:54

дмітрій. Навчися читати. олександр натякає, що в бд кладеться не бізнес логіка. Яка, в біса, бізнес логіка у зовнішніх ключах, констрейнтах? яка бізнес логіка у тому факті, що дати повинні бути в нормальному порядку? капєц блін, придумав собі шось і тепер роказує про криворуких.

Відповісти

Підтримати

Dmitry Bugay

Андрей Литвинов C Señor 06.12.2019 16:50

Но правда, но кой базе знать в каком порядке должны идти даты в бизнес-сущности?

Відповісти

Підтримати

Олександр Мощенко

Олександр Мощенко 07.12.2019 08:14

потому что это не случайные даты. Это временной промежуток.
Так как в бд нет типа «промежуток времени», то приходится собирать его из имеющихся примитивов.

Стрелу времени пока не научились поворачивать в зад, значит дата конца события не может быть меньше даты начала. Это как назвать бизнеслогикой факт того, что расстояние от центра до любой точки на окружности одинаковое.

Відповісти

Підтримати

Андрей Литвинов

Андрей Литвинов C Señor 07.12.2019 08:18

потому что это не случайные даты. Это временной промежуток.
Так как в бд нет типа «промежуток времени», то приходится собирать его из имеющихся примитивов

Это называется проф деформацией. Тип данных — это модель бизнес-домена, это же не просто данные, а еще и правила вокруг них. Им место не в бд, а в модели предметной области. Погугли DDD, aggregate root, value object.

Это как назвать бизнеслогикой факт того, что расстояние от центра до любой точки на окружности одинаковое.

Ты на верном пути, потому, что это хороший пример бизнес-правила предметной области геометрия (инварианта агрегата окружность).

Відповісти

Підтримати

Олександр Мощенко

Олександр Мощенко 07.12.2019 08:46

вот когда приложение будет работать в «предметной области геометрия» — проверка расстояния до центра окружности станет ответственностью приложения. А в бд будет лежать набор «сырых» данных. Хотя зачем тогда бд, хватит текстового файлика на шаре.

Можно назвать всё бизнес-логикой (потому что в каком-то из тдд, ддд, ооп, бжд, итд использовали слово «бизнес») и заставить приложение отвечать за всё. Правильность IPv4 адреса, коммутативность операции сложения, адекватность геокоординат, половой диморфизм, светлое социалистическое будущее.. Но я так делать не буду. БД будет отвечать за целостность данных (насколько хватит моих умений), а приложение — за работу с этими данными.

PS (добавлено). «БД будет отвечать за целостность данных» — тут я имею ввиду, что бд будет стараться проверять целостность тех данных, что в ней хранятся. Ни в коем разе это не означает, что ответственность за валидацию ложится на бд.

Відповісти

Підтримати

Андрей Литвинов

Андрей Литвинов C Señor 07.12.2019 08:48

Это называется проф деформацией.

Відповісти

Підтримати

Олександр Мощенко

Олександр Мощенко 07.12.2019 08:50

взаимно)

Відповісти

Підтримати

Андрей Литвинов

Bot Bot 07.12.2019 11:43

Хотя зачем тогда бд, хватит текстового файлика на шаре.

Бд это структура данных, которая лежит не в памяти, а на физическом носителе, потому что оперативная память дорогая. Также эта структура данных должна предоставлять набор интерфейсов или api чтобы максимально быстро вытаскивать данные из нее или наоборот записывать данные в нее(тут может быть еще длинный список требований исходя из бизнес требований)

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

Вот как мыслит типичный девелопер. То что база это центр всего проекта и IT и вообще она умеет/делает все на свете, это то, благодаря чему ДБА видно за километр.
Многие проекты действительно переходят на монгу и другие базы с другой организацией данных, блоб стораджи, а порой некоторые данные действительно пишутся в файлик на диск и это действительно эффективно решает поставленную задачу.

Відповісти

Підтримати

Олександр Мощенко

Dmitry Bugay 06.12.2019 16:56

Навчися читати

Аналогично. Я уже писал, что не против ни ФК ни там разных нотнулов.

яка бізнес логіка у тому факті, що дати повинні бути в нормальному порядку?

Кто-нибудь, пожалуйста, поясните Олександру, что «нормальный порядок» * и есть бизнес логика, потому что «нормальный порядок» именно бизнес логикой и определяется.

* если конечно под «нормальным порядком» не понимаются нормальные формы.

Відповісти

Підтримати

Олександр Мощенко

Олександр Мощенко 07.12.2019 07:54

окей. закрываем уши руками и громко, не слушая никого и перекрикивая всех, кричим «бизнеслогика-бизнеслогика-бизнеслогика-бизнеслогика...»

Відповісти

Підтримати

Dmitry Bugay

andriy dmytrenko IT Geek 03.12.2019 09:05

Юнік констрейнти вже таки в базі? Це прогрес.
Якщо подумати, то може й референси теж в БД переїдуть, і NOT NULL може?
От у нас колеги теж вважають, що NOT NULL не потрібен, а ми повинні підчищити за ними записи, що ламають їх бекенд.

Відповісти

Підтримати

Dmitry Bugay

Dmitry Bugay 06.12.2019 11:19

Не передергивай. НотНулы, форейн кеи и прочее должно быть. Но это всего лишь базовое обеспечение целостности данных, не более.
Я говорю о настоящих бизнес условиях, а не о нулл / нот нулл.
Например, что кило гвоздей получает скидку в 10% если отдел продаж сократили на 10%.

Відповісти

Підтримати

andriy dmytrenko

Andy W 06.12.2019 12:28

Например, что кило гвоздей получает скидку в 10% если отдел продаж сократили на 10%.

Це пишеться окремим слоєм у будь-якому випадку, і це очевидно всім.

Навіть, якщо хранімками — окремий набір хранімок з правилами, може навіть запхані в окрему схему, щоби не мішались під ногами

Відповісти

Підтримати

Dmitry Bugay

Andy W 20.11.2019 18:12

Подход «давайте запихнем логику в хранилки» большинством здравомыслящих людей рассматривается как зло.

ачо?

Відповісти

Підтримати

Dmitry Bugay

Dmitry Bugay 20.11.2019 22:12

ачо?

Та пацаны в падике на кортах так сказали.

Відповісти

Підтримати

Andy W

Andy W 20.11.2019 22:27

шо таке падік?

Відповісти

Підтримати

Dmitry Bugay

Dmitry Bugay 20.11.2019 22:34

подъезд на пацанском наречии.

Відповісти

Підтримати

Andy W

Олексій Пєніє 20.11.2019 00:09

На уровне знать что это такое. Любой навык в SQL получается с опытом, а без него учить бессмысленно в принципе.
Давай вопрос для самопроверки: Что не так в запросе? Не подсказывать!

update people set people.race = races.politcorrect_name from people inner join races on races.id=’nigga’

Відповісти

Підтримати

Сергій Мацюпа солодкий SDETка в house for money and sweet delights 20.11.2019 01:09

Что не так в запросе?

политкорректность

Відповісти

Підтримати

Олексій Пєніє

anonymous 20.11.2019 01:14

-

Відповісти

Підтримати

Сергій Мацюпа

Олексій Пєніє 20.11.2019 16:05

Правильно казати фемісткині

Відповісти

Підтримати

anonymous

anonymous 20.11.2019 01:14

-

Відповісти

Підтримати

Олексій Пєніє

Олексій Пєніє 20.11.2019 16:08

То что id должен быть интом — это ты сам додумал. В остальном — я ж просил, не подсказывать.

Відповісти

Підтримати

anonymous

anonymous 20.11.2019 16:15

-

Відповісти

Підтримати

Олексій Пєніє

Igor Golodnitsky те самые 5k$ в PreciseQ 03.12.2019 11:34

Крім того по конвенції завжди треба мати аутоінкремент інт айді

По женевской?)

Відповісти

Підтримати

anonymous

Vadim Koval 20.11.2019 09:23

Насчет «учить бессмыленно» это точно: пытался делать пэт-проекты — все очень быстро забывается да не доходит до нужной сложности SQL-запросов :)

Відповісти

Підтримати

Олексій Пєніє

Alexander Qel 20.11.2019 14:00

Если ты видишь сложный SQL запрос — в 99% случаев что-то пошло не так.

Відповісти

Підтримати

Vadim Koval

Олексій Пєніє 20.11.2019 16:10

Например вместо базы данных подсобачили Microsoft SQL server

Відповісти

Підтримати

Alexander Qel

Олексій Пєніє 20.11.2019 16:14

Запрос может быть громоздким, но не сложным. То ты просто ещё Drupal не видел чё генерит — вот уж где йад :)

Відповісти

Підтримати

Alexander Qel

Serhii 20.11.2019 16:41

Ну, может на пет-проектах оно и так, но на боевых обычно только со сложными работаешь, т.к. простые генерятся ОРМ-кой.

Відповісти

Підтримати

Alexander Qel

Alexander Qel 20.11.2019 17:29

Жил-да-был «боевой» проект, да не просто «боевой», а прямо воинствующе боевой. Была в том проекте ОРМ, которую всякие плебеи хейтили и при любой возможности пытались показать свое невежество выраженное в SQL, и писали они значит «сложные» SQL запросы налево и направо, но с каждым запросом оказывалось, что грызть кактус более неприятно, чем работать с ОРМ. В итоге позвали DBA, он базу поправил, пендалей «знатокам» SQL надавал и стали все опять писать запросы при помощи ОРМ. Конец.

Відповісти

Підтримати

Serhii

anonymous 20.11.2019 18:16

-

Відповісти

Підтримати

Alexander Qel

Vsevolod Iskrovsky dev 20.11.2019 18:29

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

Відповісти

Підтримати

anonymous

Андрей Литвинов C Señor 20.11.2019 18:49

Говорят OrmLite от ServiceStack норм, но я не пробовать. Да и не новая она.

Відповісти

Підтримати

anonymous

Serhii 20.11.2019 21:47

Я рекомендую github.com/linq2db/linq2db

Відповісти

Підтримати

anonymous

Дима Дима 21.11.2019 00:09

return products.Skip((currentPage — 1) * pageSize).Take(pageSize).ToList();

Дай угадаю, это превращается в offset fetch?
Вообще когда уже закончится мода натягивать linq на sql. Оно настолько непохоже, что выбивает стул из под ног.

Відповісти

Підтримати

Serhii

Left Outer Join 20.11.2019 09:45

синтаксис некорректный

Відповісти

Підтримати

Олексій Пєніє

Олексій Пєніє 20.11.2019 16:10

Пруфы, Билли

Відповісти

Підтримати

Left Outer Join

Left Outer Join 20.11.2019 16:53

create table races (id varchar(12), politcorrect_name varchar(60)); create table people (id integer auto_increment, race varchar(60));

insert into races values ('nigga', 'African');
insert into people values(NULL, 'unknown');

mysql> update people set people.race = races.politcorrect_name from people inner join races on races.id=’nigga’;
ERROR 1064 (42000): You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'from people inner join races on races.id=’nigga’' at line 1

не, я теоретически допускаю, что в других СУБД может работать, но наличие FROM в UPDATE выглядит как-то сомнительно

Відповісти

Підтримати

Олексій Пєніє

anonymous 20.11.2019 17:13

-

Відповісти

Підтримати

Left Outer Join

Олексій Пєніє 20.11.2019 17:51

Это синтаксис общий для древних баз типа MS SQL Server.
Для mysql и ему подобных синтаксис был бы сильно короче, без from

В твоём случае ты забыл убрать INTEGER из ID — уверен ругается на это.

Відповісти

Підтримати

Left Outer Join

Left Outer Join 20.11.2019 18:27

но people.id в запросе всё равно нигде не используется :P все люди станут неграми

Відповісти

Підтримати

Олексій Пєніє

Олексій Пєніє 21.11.2019 12:07

Это и была задача для ТС, которую я просил не подсказывать.
Типичнейшие грабли для джуна — забыть WHERE на апдейте.

Відповісти

Підтримати

Left Outer Join

Andy W 20.11.2019 18:19

from в update — це синтаксис mssql, sybase і може ще когось
у mysql придумали свій синтаксис — зручніший, до речі (повірити не можу, я хвалю mysql)

щось тіпа такого

update people p join races r on r.id=’nigga’ set p.race = r.politcorrect_name

само собою, цей запит містить ту ж саму помилку, що і оригінальний

Відповісти

Підтримати

Left Outer Join

Олексій Пєніє 21.11.2019 12:12

Я вообще такого стараюсь не писать, пользуясь там где можно атомарными операциями, и оооочень не люблю апдейтить 2 и более таблиц в одном запросе — это потенциальный дедлок.

Предпочитаю выражения с where exists — они более читабельны человеком, и оптимизатор куда безошибочнее целит их в индексы. По крайней мере раньше так было, сейчас вероятно разница давно стёрлась.

Здесь была чисто задача на типичную граблю — забытый WHERE на апдейте.
Мускул вроде как по дефолту такие и не пропускает.

Відповісти

Підтримати

Andy W

Left Outer Join 21.11.2019 14:48

Мускул вроде как по дефолту такие и не пропускает.

Это с чего вдруг? Если пользователь хочет апдейтнуть всё, какое имеет право мускуль ему это запрещать

Відповісти

Підтримати

Олексій Пєніє

Left Outer Join 21.11.2019 14:48

или любой другой сервер бд

Відповісти

Підтримати

Left Outer Join

anonymous 22.11.2019 19:37

-

Відповісти

Підтримати

Left Outer Join

Олександр Мощенко 21.11.2019 15:04

имхо в твоём примене забытый ЦРУКУ не так страшен, как неправильный джоин. В случае забытого where ты просто обновишь валидными политкорректными именами всех, а вот в случае кривого соединения — обновишь всех невалидными данными.

Відповісти

Підтримати

Олексій Пєніє

Konstantin Strukov 21.11.2019 15:20

забытый ЦРУКУ не так страшен, как неправильный джоин

Ну не скажи. «Забытый ЦРУКУ» даже звучит жутко, как «дальний родственник Ктулху».

Відповісти

Підтримати

Олександр Мощенко

Vasyl Boiko Software Engineer 25.11.2019 14:50

where нема, поправить раси з джойну, занулить всі інші значення

Відповісти

Підтримати

Олексій Пєніє

Голобородько 26.11.2019 02:59

Ну кроме очеведного отсутствия WHERE, можно было бы ещё поговорить за структуру базы. nigg’у ещё можно nigger’ом или negro назвать например. А people.race сделать people.race_id, а race.id сделать нормальным primary key

Відповісти

Підтримати

Олексій Пєніє

Seven Berg 19.11.2019 23:56

.NET

можно прямы езапросы писать в БД?

Відповісти

Підтримати

Андрей Литвинов C Señor 20.11.2019 06:40

Можно.

Відповісти

Підтримати

Seven Berg

ТЗ 19.11.2019 23:27

если дела идут неплохо dou.ua/forums/topic/28464
можно и не учить

Відповісти

Підтримати

Vadim Koval 20.11.2019 09:15

За 8 лет можно было и наскрести)

Відповісти

Підтримати

ТЗ

ТЗ 19.11.2019 23:25

Entity Framework detected?

Відповісти

Підтримати

Vadim Koval 20.11.2019 09:14

С ним кстати тоже не особо приходилось сталкиваться, был только проект на полгода

Відповісти

Підтримати

ТЗ

Дима Дима 19.11.2019 23:01

На каком уровне нужно знать SQL разработчику .NET?

Если кратко, то на высоком. Лично я как .NET разработчик занимаюсь на 70% написанием кучерявых романов на T-SQL. Не вылезаю из Management Studio и профайлеров.

Відповісти

Підтримати

Сергій Мацюпа солодкий SDETка в house for money and sweet delights 20.11.2019 01:14

эм
а типа database developer для этих задач?..

Відповісти

Підтримати

Дима Дима

schwarzlichtbezirk 21.11.2019 16:03

вам просто не повезло

Відповісти

Підтримати

Дима Дима

Дима Дима 21.11.2019 16:45

Это моя работа. Я занимаюсь профессионально разработкой систем где под тыщу таблиц в базе, а не сайтиками где из монги берутся коменты для статьи.

Відповісти

Підтримати

schwarzlichtbezirk

Mykhaylo Merkulov 27.11.2019 01:05

Не хочу преуменьшать ваши заслуги и почести, но мне все таки кажется что разрабатывать в 2019 году систему где под тыщу таблиц в БД — моветон и явный показатель что что-то в этой системе не так.

Відповісти

Підтримати

Дима Дима

Дима Дима 27.11.2019 02:02

Система является полностью функционирующим монолитом с 2005 года. Проекту 15 лет. Работает и приносит миллионы денег. Дурачков платить, чтобы перенести сложность из монолита в ад взаимодействия микросервисов нет. Да и не получится.

Відповісти

Підтримати

Mykhaylo Merkulov

Дмитро 27.11.2019 08:00

сталкивался с такими неоднократно. Пока конкурентных пользователей немного и вычисления просты как угол дома — максимум проблем на таких проектах сжигание огромных бюджетов на тюнинг кверей, где латенси чтения/записи может уходить за 1 секунду, а иногда и поболее. Многие просто забивают и ждут иногда и по пол минуты.
Когда появляется загрузка и сложные вычисления, под это все дело собирают нехилый бюджет покупают кластеризирлванное железо от 100 ядер и 4тб озу , и система все равно вгоняет регулярно цпу в потолок и лагает даже в руках самых заслуженных докторов наук в области субд, а продающие железо вендоры парят всякие терадаты за миллионы баксов. цикл разработки серьезной фичи около месяца или двух на таких проектах, половина из которых уходит на непонятно что, не связанное с разработкой или qa.
Когда железо регулярно отказывает а следующих 5 млн $ нет, меняют дизайн системы берут какой-то простой и быстрый in-memory key-value с шардингом получают latency на выходе 100 мс для самых сложных вычислений вместо тех секунд описанных выше, где добавление машинки в кластер стоит 100 $ per month вместо 1000000$ За покупку для prem. За счёт того что логика в языках куда более развитых чем сиквел для работы со структурами данных разными код получается понятней и лаконичней, с точки зрения удобства покрытия тестами в том числе, код максимально ci/cd friendly и за счёт изоляции позволяет такие фичи релизить за неделю.
В большинстве же случае у тех систем где все эти тысячи таблиц не более 100 пользователей overall и редко когда надо больше 1 rps, конфликты по данным ммнимальны в таких условиях, тогда вместо все это раскладывать в 1000 таблиц можно сделать несколько денормализированных документов и добавить optimistic concurrency для целостности. В итоге работа с данными буде в сотню раз быстрее происходить, будет атомарной и консистентной.
Вообщем всему свою время.

Відповісти

Підтримати

Дима Дима

Sеrgеу Bоrуssenkо Senior Tractorist 27.11.2019 10:56

Многие просто забивают и ждут иногда и по пол минуты.

Ну так энтерпрайз же — повесил крутилку «Please wait while we build your report» и все ок :)

Відповісти

Підтримати

Дмитро

Sеrgеу Bоrуssenkо Senior Tractorist 27.11.2019 11:05

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

Відповісти

Підтримати

Дима Дима

Bot Bot 27.11.2019 18:12

Это скорее всего апп для энтерпрайза и его внутренних нужд, на рост пользователей и прочие стартаповские шутки там насрать. Такие виды приложений живут кардинально другой жизнью и в разных вселенных.

Відповісти

Підтримати

Sеrgеу Bоrуssenkо

Sеrgеу Bоrуssenkо Senior Tractorist 27.11.2019 18:19

Энтерпрайзовский внутренний апп не может «приносить миллионы» по определению. Ну если мы не про миллионы галерам говорим :)

Відповісти

Підтримати

Bot Bot

Bot Bot 27.11.2019 18:23

Может сам апп в энетрпразе и не приносит миллионы, но без него сам энерпрайз тупо встанет и не видать ни миллионов ни бизнеса. А стартапы вообще только убытки генерят и проедают инвестиции ))))
Это просто как считать.

Відповісти

Підтримати

Sеrgеу Bоrуssenkо

Sеrgеу Bоrуssenkо Senior Tractorist 27.11.2019 18:30

Сам автор четко написал

Проекту 15 лет. Работает и приносит миллионы денег.

Поэтому это не про внутренний продукт.
Кроме стартапов есть еще множество работающих бизнесов, и энтерпрайз решения это не про внутренние продукты, в конце концов и стартапы имеют свои внутренние продукты для своих нужд.
Энтерпрайз решения это B2B рынок, где клиентами являются корпорации, а они уже бывают маленькие, средние или большие.

Відповісти

Підтримати

Bot Bot

Bot Bot 27.11.2019 21:07

Как он приносит не описал, фейсбук тоже не приносит выгоды как и поисковик гугла, но оба зарабатывают просто горы денег на рекламе и инфе пользователей. Так что трактовка прибыльности очень размыта.

Відповісти

Підтримати

Sеrgеу Bоrуssenkо

Sеrgеу Bоrуssenkо Senior Tractorist 27.11.2019 22:41

А к чему в данном случае аналогия с фейсбуком или гуглом? Они тоже внутренние аппы энтерпрайза?
К чему вообще смешивать бизнес-модель с типом целевого рынка?

Відповісти

Підтримати

Bot Bot

Bot Bot 27.11.2019 23:29

Система является полностью функционирующим монолитом с 2005 года. Проекту 15 лет. Работает и приносит миллионы денег.

Відповісти

Підтримати

Sеrgеу Bоrуssenkо

Sеrgеу Bоrуssenkо Senior Tractorist 28.11.2019 01:11

Какая разница каким образом на данном продукте зарабатывают? Это лишь детали бизнес-модели. Внутренний Энтерпрайз продукт по определению не может приносить прибыли — он нужен для обеспечения внутренних процессов в компании, а не для продажи и зарабатывания денег. И заказчиком и клиентом в данном случае выступает одна и та же компания. То, что такая система может быть критическая для жизнеспособности бизнеса я и не спорю. Твой рабочий компьютер не приносит тебе денег, но он критический инструмент, который обеспечивает твой процесс зарабатывания денег.

А про Фейсбук и Гугл ты вообще какую-то чушь пишешь. То что сервис имеет бесплатный доступ, а зарабатывает на рекламе не означает что он от этого стал не прибыльным. Реклама это лишь один из видов монетизациии сервиса, так же как и платный доступ

Відповісти

Підтримати

Bot Bot

Bot Bot 28.11.2019 11:09

Какая разница каким образом на данном продукте зарабатывают?

На этом можно и закончить.

Если решают ввалить кучу бабла в разработку\супоорт энетрпарйз
проекта, значит есть профит, об этом он и написал.

Работает и приносит миллионы денег.

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

Відповісти

Підтримати

Sеrgеу Bоrуssenkо

Sеrgеу Bоrуssenkо Senior Tractorist 28.11.2019 17:31

Слив засчитан

Відповісти

Підтримати

Bot Bot

Bot Bot 28.11.2019 20:54

Все верно, сливайся.

Відповісти

Підтримати

Sеrgеу Bоrуssenkо

Sеrgеу Bоrуssenkо Senior Tractorist 27.11.2019 10:49

Как романтично ты про кровавый энтерпрайз пишешь :)

Відповісти

Підтримати

Дима Дима

Bot Bot 27.11.2019 18:17

Многим это интересно, и не интересен аджайл стартап, где сегодня ты пишешь сервис на монге, завтра это уже видео чат и ты тестировщик, после завтра это UI для микро-кредитов и ты девопс :-))))

Відповісти

Підтримати

Sеrgеу Bоrуssenkо

Sеrgеу Bоrуssenkо Senior Tractorist 27.11.2019 18:22