Кто поделится Best Practice? Где в структуре проекта правильнее реализовать таблицы, отражающие связь "многие-ко-многим"?
Есть договора, ConractModule с ConractEntity. Есть продукты, ProductModule с ProductEntity.
И нужно сделать спецификацию в договоре, то есть перечень продуктов, включенных в договор. То есть ProductInContractEntity (поля contract_id, product_id. По id договора получаем список id продуктов в данном договоре).
Как правильнее сделать структуру проекта? С учетом того, что и в контроллере ConractModule , и в контроллере ProductModule , могут понадобится данные из ProductInContractEntity ?
Варианты:
Делать внутри продуктов. То есть ProductInContractEntity описать внутри файла product.entity.ts, импортировать в ProductService, инжектировать второй репозиторий, и описать методы, работающие с репозиторием. Получается не очень красиво, дубликаты всех методов. Например, findAll будет для productRepository, и будет второй findAllForContract для productInContractRepository. Затем придется импортировать модуль ProductModule в ContractModule, и в контроллере в ContractController (/backend/contract/product), который выдает список продуктов в договоре, обращаться к этому productService.findAllForContract
Делать с точностью наоборот, ProductInContractEntity описать внутри файла contract.entity.ts, и т.д. Опять дубликаты методов, и опять придется наоборот, импортировать ContractModule в ProductModule , потому что в контроллере продуктов ProductController может быть метод, читающий данные из ProductInContractEntity . Например дай список договоров, где встречается определенный продукт (/backend/product/contract).
Делать отдельный модуль ProductInContractModule, или SpesificationModule назвать его, и в него импортировать ContractModule и ProductModule, и все запросы, где нужны смешанные данные, реализовать в этом модуле ProductInContractModule. Но во первых появляется третий контроллер (/backend/speca), это для фронта неудобно, или некрасиво. И второе, есть еще другие сущности в договоре, например перечень услуг в договоре. Или перечень задействованных в договоре ресурсов. И что же, кучу модулей теперь городить?
Маленькая страна, маленькая покупательская способность населения. Крупного частного бизнеса, делающего деньги на населении - исчезающе мало. Поэтому ИТ компаний, как то связанных с обслуживанием этого частного бизнеса, еще меньше. В России, например, может существовать частный Озон.ру, и вокруг него есть какой то субподряд. И т.п. А в Казахстане не может существовать Озон.ру.
Все крупные ИТ-проекты в Казахстане крутятся вокруг нескольких гос и квазигос организаций. А что это такое, и как это все работает - вы и сами знаете, так же как и в России (и в Украине). Только есть специфика, в России, опять же, много гос и квази гос, а в Казахстане их мало.
Например, банки. В России, насколько я понимаю, есть несколько десятков банков, которые могут заказать какой то ИТ-проект. В Казахстане три - четыре банка, у которых могут быть внятные проекты (бюджеты). Их них один это Сбер Казахстан, который живет своей жизнью.
В целом ситуация такая, за редким исключением.
Удивительное название у статьи, даже зашел почитать. ))) Но кажется, автор что то другое имел в виду, про Телеграм канал, что ли.
Не сочтите за ..., но чтобы отбивать вложения в RPA, нужно с помощью RPA заменять сотрудников с высокой оплатой труда, и с повторяющимися операциями. И чтобы эту операцию было трудно (дорого) автоматизировать в той самой системе, поверх которой запускаем RPA. Повторяющиеся операции это в большинстве случаев бухгалтерия. Бухгалтерия это 1С, которая вообще далека от "дорого". Остается SAP, где добавить запятую это тех.задание и тестовый стенд, и чек с ... нулями. Итого RPA в нашей стране применима в очень узкой нише "чего то сделать вокруг SAP". В США да, там зарплаты высокие, и сегментов, где применяется RPA, на порядки больше. Поэтому думается, что в статьях на Хабре мало смысла. Лучше делать целевые рассылки в большие конторы, где используют SAP.
Для наглядности, добавили бы примерные расчеты, сколько кг нужно ядерного топлива, чтобы разогнать корабль весом 1 кг до скорости 50% от скорости света? Допустим, что у корабля какой то двигатель с КПД 100%, то есть вся энергия ядерного деления переводится в ускорение
Посмотрел на сайте Комитета госдоходов Казахстана (налоговая), БИН Яндекс Такси 161240022428. Уплата налогов за 2020 год — 68 млн тенге, это около $150 000. Комитет госдоходов в этой сумме отражает все налоги, в том числе налоги с заработной платы. Поэтому можно предположить, что это налоги с заработной платы сотрудников офиса Яндекс Такси в Казахстане. В общем, сумма маленькая. Из чего можно предположить, что Яндекс Такси не платит налоги собственно с доходов от услуг такси в Казахстане.
Не сказать, что Яндекс Такси много инвестировал в экономику Казахстана.
Потому что вся эта дискуссия она как то на верхнем уровне. А на низком уровне у человека все заточено под продолжение рода. Когда ты руку отдергиваешь от горячей сковороды — это продолжение рода. Когда ночью из за угла выпрыгивает кошка, ты пугаешься, выброс адреналина, учащение пульса, прилив сил — это продолжение рода. Когда гормоны выделяются при виде сексуального объекта — это продолжение рода (если конечно от сидячего образа компьютерной жизни ничего не атрофировалось, и есть чему выделяться ))) ). И т.п.
В целом так, у молодой особи мужского рода есть список пожеланий. У большинства особей он примерно одинаковый, за исключением технических деталей:
а) Размер колесных дисков в пункте 1.
б) Рост, цвет волос и цвет кожи в пункте 2.
в) Бренды в остальных пунктах.
Ну порядок пунктов может меняться.
Далее, упростим до двух вариантов:
Вариант 1: Когда особь в силу каких то случайностей, или установок родителей, зарабатывает деньги, то особь удовлетворяет свой список пожеланий и получает удовольствие — дофамин. Но зарабатывать деньги, и ночами играть в Доту — трудное сочетание, поэтому на этом этапе особь не играет, по крайней мере много не играет.
После удовлетворения списка осознается его бренность, и ценность продолжения рода, и детей. Бонусы к детям выше описаны, поэтому на этом этапе особь тоже не играет, по крайней мере много.
Вариант 2: Когда особь в силу каких то случайностей, или установок родителей, НЕ зарабатывает деньги, а начинает получать дофамин в виртуальных достижениях. В этом случае список желаний остается не выполненным, но денег на его выполнение нет. Потому что зарабатывать деньги, и ночами играть в Доту — трудное сочетание. Остается продолжать получать дофамин в виртуальных достижениях. Так как список не выполнен, то до этапа осознания бренности списка особь доходит. Особь выдумывает кучу логичных оправданий, почему дети не нужны.
Итого: Игромания удел лузеров. Если под лузерством мы понимаем материальный достаток. И если говорим о большистве случаев, киберспорт конечно не рассматриваем. То тогда да, вот так, игромания удел лузеров.
Кто поделится Best Practice? Где в структуре проекта правильнее реализовать таблицы, отражающие связь "многие-ко-многим"?
Есть договора, ConractModule с ConractEntity. Есть продукты, ProductModule с ProductEntity.
И нужно сделать спецификацию в договоре, то есть перечень продуктов, включенных в договор. То есть ProductInContractEntity (поля contract_id, product_id. По id договора получаем список id продуктов в данном договоре).
Как правильнее сделать структуру проекта? С учетом того, что и в контроллере ConractModule , и в контроллере ProductModule , могут понадобится данные из ProductInContractEntity ?
Варианты:
Делать внутри продуктов. То есть ProductInContractEntity описать внутри файла product.entity.ts, импортировать в ProductService, инжектировать второй репозиторий, и описать методы, работающие с репозиторием. Получается не очень красиво, дубликаты всех методов. Например, findAll будет для productRepository, и будет второй findAllForContract для productInContractRepository. Затем придется импортировать модуль ProductModule в ContractModule, и в контроллере в ContractController (/backend/contract/product), который выдает список продуктов в договоре, обращаться к этому productService.findAllForContract
Делать с точностью наоборот, ProductInContractEntity описать внутри файла contract.entity.ts, и т.д. Опять дубликаты методов, и опять придется наоборот, импортировать ContractModule в ProductModule , потому что в контроллере продуктов ProductController может быть метод, читающий данные из ProductInContractEntity . Например дай список договоров, где встречается определенный продукт (/backend/product/contract).
Делать отдельный модуль ProductInContractModule, или SpesificationModule назвать его, и в него импортировать ContractModule и ProductModule, и все запросы, где нужны смешанные данные, реализовать в этом модуле ProductInContractModule. Но во первых появляется третий контроллер (/backend/speca), это для фронта неудобно, или некрасиво. И второе, есть еще другие сущности в договоре, например перечень услуг в договоре. Или перечень задействованных в договоре ресурсов. И что же, кучу модулей теперь городить?
Спасибо, опишу в следующей статье
Я имел в виду по населению маленькая
Будут
В Казахстане нет ИТ-бизнеса.
Маленькая страна, маленькая покупательская способность населения. Крупного частного бизнеса, делающего деньги на населении - исчезающе мало. Поэтому ИТ компаний, как то связанных с обслуживанием этого частного бизнеса, еще меньше. В России, например, может существовать частный Озон.ру, и вокруг него есть какой то субподряд. И т.п. А в Казахстане не может существовать Озон.ру.
Все крупные ИТ-проекты в Казахстане крутятся вокруг нескольких гос и квазигос организаций. А что это такое, и как это все работает - вы и сами знаете, так же как и в России (и в Украине). Только есть специфика, в России, опять же, много гос и квази гос, а в Казахстане их мало.
Например, банки. В России, насколько я понимаю, есть несколько десятков банков, которые могут заказать какой то ИТ-проект. В Казахстане три - четыре банка, у которых могут быть внятные проекты (бюджеты). Их них один это Сбер Казахстан, который живет своей жизнью.
В целом ситуация такая, за редким исключением.
Удивительное название у статьи, даже зашел почитать. ))) Но кажется, автор что то другое имел в виду, про Телеграм канал, что ли.
Не сочтите за ..., но чтобы отбивать вложения в RPA, нужно с помощью RPA заменять сотрудников с высокой оплатой труда, и с повторяющимися операциями. И чтобы эту операцию было трудно (дорого) автоматизировать в той самой системе, поверх которой запускаем RPA. Повторяющиеся операции это в большинстве случаев бухгалтерия. Бухгалтерия это 1С, которая вообще далека от "дорого". Остается SAP, где добавить запятую это тех.задание и тестовый стенд, и чек с ... нулями. Итого RPA в нашей стране применима в очень узкой нише "чего то сделать вокруг SAP". В США да, там зарплаты высокие, и сегментов, где применяется RPA, на порядки больше. Поэтому думается, что в статьях на Хабре мало смысла. Лучше делать целевые рассылки в большие конторы, где используют SAP.
Ну не совсем так, в явной форме. Я сначала сделал, в потом понял, что это большая проблема.
Спасибо, сделаю вторую версию модели
Спасибо, попробую. С балансом классов все плохо.
Для наглядности, добавили бы примерные расчеты, сколько кг нужно ядерного топлива, чтобы разогнать корабль весом 1 кг до скорости 50% от скорости света? Допустим, что у корабля какой то двигатель с КПД 100%, то есть вся энергия ядерного деления переводится в ускорение
кажется нет, нельзя, в этой таблице напротив типа сообщений voice стоит крестик красный:
https://developers.facebook.com/docs/messenger-platform/instagram/features/send-message/
Это тонкий юмор? Это ведь обмен сообщениями, конечно можно. Я не понял вопроса
Как обосновать руководителю бюджет на RPA, если лицензия на робота стоит $20 000 в год, а бухгалтер, которого заменяет робот, стоит $400 в месяц?
Не сказать, что Яндекс Такси много инвестировал в экономику Казахстана.
Есть логичное объяснение, в животе малыш привык к покачиванию, и поэтому это действует успокаивающе
В целом так, у молодой особи мужского рода есть список пожеланий. У большинства особей он примерно одинаковый, за исключением технических деталей:
а) Размер колесных дисков в пункте 1.
б) Рост, цвет волос и цвет кожи в пункте 2.
в) Бренды в остальных пунктах.
Ну порядок пунктов может меняться.
Далее, упростим до двух вариантов:
Вариант 1: Когда особь в силу каких то случайностей, или установок родителей, зарабатывает деньги, то особь удовлетворяет свой список пожеланий и получает удовольствие — дофамин. Но зарабатывать деньги, и ночами играть в Доту — трудное сочетание, поэтому на этом этапе особь не играет, по крайней мере много не играет.
После удовлетворения списка осознается его бренность, и ценность продолжения рода, и детей. Бонусы к детям выше описаны, поэтому на этом этапе особь тоже не играет, по крайней мере много.
Вариант 2: Когда особь в силу каких то случайностей, или установок родителей, НЕ зарабатывает деньги, а начинает получать дофамин в виртуальных достижениях. В этом случае список желаний остается не выполненным, но денег на его выполнение нет. Потому что зарабатывать деньги, и ночами играть в Доту — трудное сочетание. Остается продолжать получать дофамин в виртуальных достижениях. Так как список не выполнен, то до этапа осознания бренности списка особь доходит. Особь выдумывает кучу логичных оправданий, почему дети не нужны.
Итого: Игромания удел лузеров. Если под лузерством мы понимаем материальный достаток. И если говорим о большистве случаев, киберспорт конечно не рассматриваем. То тогда да, вот так, игромания удел лузеров.