1) На каких конкретно стадиях PRP терапия эффективна? В острый период травмы или после реабилитации когда всё вроде зажило но может где-то болеть.
2) Как на счёт инъекций гормонов в сустав? Насколько это вредно или опасно?
3) Есть PRP терапия за 1000 рублей сеанс. А есть SVF (оборудование Артекс) терапия, возможно включающая PRP… помоему 50к то ли за сеанс, то ли за курс. SVF — это развод?
Ну с другой стороны, они много работают с проф. спортсменами. а там задача — лет 5 побегать, а потом на пенсию с инвалидностью. Так могут колоть гормоны в сустав и прочие вещи со спорной безопасностью для здоровья.
При том что то что их нужно вообще отличать чёрное от белого не очевидно. С точки зрения обывателя незнакомого с системой — отличать не нужно. Тут мы выяснили что нужно habr.com/ru/post/470155/#comment_20714405 Но в приведённом законе это не описано.
Не понял. Буквы+цифры на военном номере могут совпадать с таковыми на невоенном? А разве буквы+цифры не должны быть уникальны среди всех типов номеров?
Здесь мы говорим про компьютер, где минимальный квант времени — один такт. Так что ноль секунд плюс бесконечно малое и есть ноль секунд. Мы можем прочитать время и уже через полтакта оно перешагнёт в следующую секунду. Это будет для нас ноль секунд.
Отличная статья! Большинство статей про сервисную архитектуру, что я видел на хабре, сводятся к низкоуровневым темам в зоне devops. А про высокоуровневое проектирование эта лучшая статья что я видел здесь.
Если разрешение часов 1 секунда, то если подождать от текущего момента до следующий секунды, то ожидание будет длится от 0 до 1 секунды. Т.е. в худшем случае оно будет 0 секунд.
Таким если мы хотим выждать любое гарантировано ненулевое время, то нужно к текущему времени прибавлять минимум 2 секунды.
Это и сейчас актуально, часто пользовался.
После появления Exportа он лез в Firebird. DGPP тоже лез в Firebird. Т.е. у Export и DGPP была общая база Firebird.
Вопрос. Не было ли проблем с тем что, в процессе развития продукта (добавления новой фичи и т.п.) нужно модифицировать структуру БД,
и нужно было править одновременно и код Export и код DGPP? И мало того что править, так и релизить правки в один момент.
И с какого момента Export перестал лезть в базу? Как удалось базу заменить на ESB?
Запросы (то есть VIEW) в реализацию добавлять нельзя (в смысле что VIEW наследовать от таблиц / друг от друга).
Ну может это для кого-то недостаток. Но вы пишите " зачем в PostgreSQL наследование вообще добавляли — неясно."
Хотя тут как раз наследование — отличная и незаменимая фича.
Есть люди, которые БД используют не так хардкорно. Может даже используют ORM. И их большинство.
View им в этом не нужны. А эта фича — как раз возможность хранить данные с наследованием. И именно структурированное хранение данных первичная фича базы. View же для тех, кто пытается и бизнеслогику реализовать на SQL, что часто тупиковый путь.
В PostgreSQL формально наследование таблиц есть, но не более того. А учитывая, что смысла в наследовании без полиморфизма нет практически никакого, зачем в PostgreSQL наследование вообще добавляли — неясно.
Вообще, если провести аналогию со структурным программированием, полиморфизм в SQL, по идее, должен был выглядеть как возможность создания абстрактного представления, в который можно добавлять различные UNION'ы в качестве реализации, то есть что-то вроде:
EXTEND VIEW Detail
SELECT receipt AS document, quantity FROM receiptDetail;
…
EXTEND VIEW X
SELECT shipment AS document, quantity FROM shipmentDetail;
Храните базовую таблицу document. С полем amount например. От неё наследуйте receipt и shipment. В них будут уникальные поля для этих типов документов.
Так что всё делается, только «наоборот». И делается правильнее. т.к. БД это про хранение, и нечего делать «интерфейсы» выдавая одни поля за другие.
2) Как на счёт инъекций гормонов в сустав? Насколько это вредно или опасно?
3) Есть PRP терапия за 1000 рублей сеанс. А есть SVF (оборудование Артекс) терапия, возможно включающая PRP… помоему 50к то ли за сеанс, то ли за курс. SVF — это развод?
ну кем надо быть чтобы на такое согласиться?
Таким если мы хотим выждать любое гарантировано ненулевое время, то нужно к текущему времени прибавлять минимум 2 секунды.
Это и сейчас актуально, часто пользовался.
Вопрос. Не было ли проблем с тем что, в процессе развития продукта (добавления новой фичи и т.п.) нужно модифицировать структуру БД,
и нужно было править одновременно и код Export и код DGPP? И мало того что править, так и релизить правки в один момент.
И с какого момента Export перестал лезть в базу? Как удалось базу заменить на ESB?
Ну может это для кого-то недостаток. Но вы пишите " зачем в PostgreSQL наследование вообще добавляли — неясно."
Хотя тут как раз наследование — отличная и незаменимая фича.
Есть люди, которые БД используют не так хардкорно. Может даже используют ORM. И их большинство.
View им в этом не нужны. А эта фича — как раз возможность хранить данные с наследованием. И именно структурированное хранение данных первичная фича базы. View же для тех, кто пытается и бизнеслогику реализовать на SQL, что часто тупиковый путь.
Да есть пример в документации, где описано зачем
www.postgresql.org/docs/10/tutorial-inheritance.html
Храните базовую таблицу document. С полем amount например. От неё наследуйте receipt и shipment. В них будут уникальные поля для этих типов документов.
Так что всё делается, только «наоборот». И делается правильнее. т.к. БД это про хранение, и нечего делать «интерфейсы» выдавая одни поля за другие.