Никогда не понимал желание аналитика залезть в области, где ему делать нечего. Ваша обязанность - описать пользовательские сценарии, и результаты выполнения этих сценариев. Для этого вообще не нужны ни Swagger в частности, ни OpenAPI в целом. Поскольку тот же Swagger никак не может описать изменения в БД после выполнения сценария. А оно как бы надо. Ну и 2 ОЧЕНЬ больших косяка (это как пример, на самом деле их даже не десяток) у вас лично, при попытке влезть в чужую предметную область:
Ограничение на catId стоит только not null. Подскажите, он у вас действительно может быть отрицательным? Зачем? Это была неудачная попытка влезть в область системного архитектора.
Поля с датами у вас date_created и date_updated. Жестко прописаны. Например в Laravel эти поля по умолчанию называются created_at и updated_at. Таким образом вы создаете абсолютно ненужную работу программисту, залезая в его область.
Ну и как добрый совет, почитайте уже наконец про BDD (Behavior-driven development). Вот это уже сильно ближе к работе аналитика, нежели перенос описашек из Сваггера в Конфлюенс.
Хм… Конфиденциальны ли, к примеру, персональные данные вы тоже определяете для себя сами? А сведения, составляяющие адвокатскую или врачебную тайну?
Единственное, что вы можете сами определить — набор сведений, составляющих коммерческую тайну, если это не противоречит законодательству (объявить коммерческой, как многие это любят делать, тайной зарплату сотрудника нельзя, например). Не путайте эти понятия.
А еще адекватный взрослый человек должен прекрасно понимать, что никому "там" он не нужен без профильного образования, опыта работы, рекомендаций, портфолио (не обязательно все пункты сразу). Ну и ещё момент: очень сложно вот так вот взять и кардинально поменять свою жизнь, когда в ней столько якорей. Это я если что про ребенка, который уже с репетитором занимается. Так что согласен с вами, статья с большой долей вероятности ничего общего с действительностью не имеет.
Жил был программист. Программист как программист, уровня миддл или даже выше. Но была с ним одно беда — не любил он хранимую рутину. Не, триггер на получение ключа из сиквенса он еще написать мог, но все что больше — считал плохим тоном. Ибо логика должна была быть на миддл-слое. И получил он как-то раз задачу, обновить данные в неком дереве, которое представляло из себя сеть Петри. Только обновить данные нужно было хитро, в зависимости от результата агрегации данных нижестоящих узлов. Ну и решил он задачку как обычно. А потом остался он без премии, и чуть не остался без работы. Поскольку мозг нужно включать, и понимать, что иногда накладные расходы на многократную передачу данных на сторону, агрегацию их там и последующее их обновление могут быть такими, что будут по сути Dos-атакой. База лежала 4 часа.
Вот и вся сказка.
ПС: а еще он забыл отключить индексы, за что ему поставили отдельный памятник.
Они не денормализованы, они разрежены. Это 2 разных термина, и означают они немного разные вещи. Хотя внешне это похоже. Что же касается "не умели SQL", то тут проблема в том, что языка структурных запросов просто недостаточно для работы с OLAP-кубами. Формально, нормально транслировать их научилась только одна СУБД (Oracle). Для всех остальных это ад, и OLAP для них этот как правило отдельное ПО, которое базу использует только как хранилище. И да, в качестве хранилища можно использовать noSQL решения, но реализация MOLAP (на многомерных структурах) по сути является костылем, и в разы сложнее реализации ROLAP (на реляционных структурах).
Нет. Описанием OLAP-куба является "проекция отношений фактов". Что само по себе термин из реляционной алгебры. Ну и хронологически, OLAP-кубы существовали до появления современных noSQL решений.
Поверьте, в накладные расходы уровня сети/памяти вы в приведенном кейсе упретесь в разы быстрее, нежели в производительность БД. Собственно, у Oracle есть нативные витрины данных для OLAP из коробки, и с ними никогда не было никаких проблем.
Ни в коем случае. Есть нативные средства. К примеру, для Oracle — это гетерогенные службы (heterogeneous services). Только вот если мы говорим о способе общения как у сервисов (а один сервис ничего не знает о состоянии другого, и общение идет через апи) то это скорее transparent gateways или rpc (один инстанс базы вполне в состоянии дернуть хранимую другого инстанса и ничего не знать при этом о структурах данных второго, что как раз ближе всего к сервисной архитектуре).
А применять правила НЕ хай-лоад разработки для всей разработки корректно? И, на секундочку, в описанном мной кейсе уровень хай-лоада приблизительно равен нулю.
Огромное пожелание автору: прежде чем писать о плюсах и минусах хранимок, попробуйте реализовать на middle-слое бизнес-логику витрин данных для сложной аналитики на базе террабайт так в 200.
Согласен чуть больше чем на 146 процентов. Скажу больше — очень многие компании с 50+ офисов продаж и/или обслуживания начинают именно с процессов. Сначала какая-нибудь Cammunda, потом какая-нибудь CRM. Но, надо отдельно заметить, что у таких компаний есть ресурсы для всех этих внедрений, которых нет у малого бизнеса.
Вы сейчас говорите о том, что нет 100% гарантии защиты информации. И я с вами не спорю. По той просто причине, что я говорю совершенно о другом, а именно: лучший способ защитить ноутбук (а речь в статье идет именно о нем) от утечки информации — не хранить на нем эту информацию вообще.
Приду я такой весь зашифрованный домой и… пропущу вперед ГНР. Потому что если у вас не стоит дома сигнализация при той цене информации, которая там хранится, то паяльник будет вам лучшим лекарством от скудоумия.
Давайте примем за неоспоримые факты 2 вещи: против паяльника приема нет и то что стоимость украденной информации должна превышать стоимость взлома. Иначе разумнее использовать паяльник.
Если ваша информация стоит тысячи — подойдет домашний нас, обычный open-vpn. Если миллионы — сервер в колокейшене с нормальной охраной, оборудованием и прочим. Если миллиарды — тоже есть решения. К которым относится и персональная охрана.
А все дело в том, что изначально задан абсолютно не верный постулат о том, что программист должен писать "простой код". Ничего подобного! Программист должен писать код, обеспечивающий минимальную стоимость владения. Что означает, что код должен легко тестироваться, легко изменяться (читаемость кода входит именно сюда) и легко расширяться. Все. Больше программист никому ничего не должен.
Ну а инфраструктуру-то как правильно развивать? Или единственный способ — "обратитесь к нам, и мы расскажем о подводных камнях, о которых вы и так знаете"? Статья абсолютно не о чем.
Никогда не понимал желание аналитика залезть в области, где ему делать нечего. Ваша обязанность - описать пользовательские сценарии, и результаты выполнения этих сценариев. Для этого вообще не нужны ни Swagger в частности, ни OpenAPI в целом. Поскольку тот же Swagger никак не может описать изменения в БД после выполнения сценария. А оно как бы надо. Ну и 2 ОЧЕНЬ больших косяка (это как пример, на самом деле их даже не десяток) у вас лично, при попытке влезть в чужую предметную область:
Ограничение на catId стоит только not null. Подскажите, он у вас действительно может быть отрицательным? Зачем? Это была неудачная попытка влезть в область системного архитектора.
Поля с датами у вас date_created и date_updated. Жестко прописаны. Например в Laravel эти поля по умолчанию называются created_at и updated_at. Таким образом вы создаете абсолютно ненужную работу программисту, залезая в его область.
Ну и как добрый совет, почитайте уже наконец про BDD (Behavior-driven development). Вот это уже сильно ближе к работе аналитика, нежели перенос описашек из Сваггера в Конфлюенс.
Единственное, что вы можете сами определить — набор сведений, составляющих коммерческую тайну, если это не противоречит законодательству (объявить коммерческой, как многие это любят делать, тайной зарплату сотрудника нельзя, например). Не путайте эти понятия.
А еще адекватный взрослый человек должен прекрасно понимать, что никому "там" он не нужен без профильного образования, опыта работы, рекомендаций, портфолио (не обязательно все пункты сразу). Ну и ещё момент: очень сложно вот так вот взять и кардинально поменять свою жизнь, когда в ней столько якорей. Это я если что про ребенка, который уже с репетитором занимается. Так что согласен с вами, статья с большой долей вероятности ничего общего с действительностью не имеет.
Давайте расскажу сказку на ночь.
Жил был программист. Программист как программист, уровня миддл или даже выше. Но была с ним одно беда — не любил он хранимую рутину. Не, триггер на получение ключа из сиквенса он еще написать мог, но все что больше — считал плохим тоном. Ибо логика должна была быть на миддл-слое. И получил он как-то раз задачу, обновить данные в неком дереве, которое представляло из себя сеть Петри. Только обновить данные нужно было хитро, в зависимости от результата агрегации данных нижестоящих узлов. Ну и решил он задачку как обычно. А потом остался он без премии, и чуть не остался без работы. Поскольку мозг нужно включать, и понимать, что иногда накладные расходы на многократную передачу данных на сторону, агрегацию их там и последующее их обновление могут быть такими, что будут по сути Dos-атакой. База лежала 4 часа.
Вот и вся сказка.
ПС: а еще он забыл отключить индексы, за что ему поставили отдельный памятник.
Они не денормализованы, они разрежены. Это 2 разных термина, и означают они немного разные вещи. Хотя внешне это похоже. Что же касается "не умели SQL", то тут проблема в том, что языка структурных запросов просто недостаточно для работы с OLAP-кубами. Формально, нормально транслировать их научилась только одна СУБД (Oracle). Для всех остальных это ад, и OLAP для них этот как правило отдельное ПО, которое базу использует только как хранилище. И да, в качестве хранилища можно использовать noSQL решения, но реализация MOLAP (на многомерных структурах) по сути является костылем, и в разы сложнее реализации ROLAP (на реляционных структурах).
Нет. Описанием OLAP-куба является "проекция отношений фактов". Что само по себе термин из реляционной алгебры. Ну и хронологически, OLAP-кубы существовали до появления современных noSQL решений.
OLAP-кубы на noSQL решениях это сильно. Звучит как заявка на победу. Прямо вижу как вы пытаетесь реализовать снежинку на Mongo...
Поверьте, в накладные расходы уровня сети/памяти вы в приведенном кейсе упретесь в разы быстрее, нежели в производительность БД. Собственно, у Oracle есть нативные витрины данных для OLAP из коробки, и с ними никогда не было никаких проблем.
Ни в коем случае. Есть нативные средства. К примеру, для Oracle — это гетерогенные службы (heterogeneous services). Только вот если мы говорим о способе общения как у сервисов (а один сервис ничего не знает о состоянии другого, и общение идет через апи) то это скорее transparent gateways или rpc (один инстанс базы вполне в состоянии дернуть хранимую другого инстанса и ничего не знать при этом о структурах данных второго, что как раз ближе всего к сервисной архитектуре).
Нет ровным счетом никаких проблем с распилом базы на куски аналогично распилу монолита на сервисы. Тут единственная проблема — лицензии.
А применять правила НЕ хай-лоад разработки для всей разработки корректно? И, на секундочку, в описанном мной кейсе уровень хай-лоада приблизительно равен нулю.
Огромное пожелание автору: прежде чем писать о плюсах и минусах хранимок, попробуйте реализовать на middle-слое бизнес-логику витрин данных для сложной аналитики на базе террабайт так в 200.
Согласен чуть больше чем на 146 процентов. Скажу больше — очень многие компании с 50+ офисов продаж и/или обслуживания начинают именно с процессов. Сначала какая-нибудь Cammunda, потом какая-нибудь CRM. Но, надо отдельно заметить, что у таких компаний есть ресурсы для всех этих внедрений, которых нет у малого бизнеса.
Давайте примем за неоспоримые факты 2 вещи: против паяльника приема нет и то что стоимость украденной информации должна превышать стоимость взлома. Иначе разумнее использовать паяльник.
Если ваша информация стоит тысячи — подойдет домашний нас, обычный open-vpn. Если миллионы — сервер в колокейшене с нормальной охраной, оборудованием и прочим. Если миллиарды — тоже есть решения. К которым относится и персональная охрана.
Пс: не на то ответил, сорри.
9 Не храните на ноутбуке критически важной информации. Работайте с ней через приватное облако, доступ к которому осуществляется по vpn.
Собственно, этот пункт может решить большую часть проблем.
А все дело в том, что изначально задан абсолютно не верный постулат о том, что программист должен писать "простой код". Ничего подобного! Программист должен писать код, обеспечивающий минимальную стоимость владения. Что означает, что код должен легко тестироваться, легко изменяться (читаемость кода входит именно сюда) и легко расширяться. Все. Больше программист никому ничего не должен.
Ну а инфраструктуру-то как правильно развивать? Или единственный способ — "обратитесь к нам, и мы расскажем о подводных камнях, о которых вы и так знаете"? Статья абсолютно не о чем.
Не вводите людей в заблуждение, авторские права прекрасно передаются за исключением трех.