Пссс...готовых ERP систем на самом деле не существует, все что продают из коробки калечит бизнес процессы предприятия. Так что по итогу вы или сами сводите кучу гетерогенных систем в единый комплекс, дописывая что-то на своём любимом языке программирования, или в меру открытости исходников для доработки допиливаете какое-то готовое уже купленное и поставленное ERP решение. Второй вариант - тупик и смерть вас как программиста. Первый - не принесёт больших денег, так как вы будете работать по факту на одно предприятие и не сможете тиражировать результат на остальные предприятия. Ну или найти команду единомышленников и в подвале колхозить что-то своё, но это путь героев и мучеников. Мда, как-то мрачно все это прозвучало, особенно учитывая, что я сам занимаюсь автоматизацией (в медицине)
Ну если начать читать, как делает запрос, то в это можно уйти на неделю (а то и вовсе не вернуться). Возьмите вариант Евгений Вольф или мой, они вам выдадут 12 пар без каких либо гарантий кто из какой таблицы с кем окажется в паре. Но смысла в этом и правда на первый взгляд нет. У вас может в одном выполнении запроса сформироваться пара из 1 и 1 item, а в следующий раз из 1 и 8, например
Вопрос в том, в каком порядке должно идти сопоставление пар этих элементов. sql не гарантирует вам порядок строк при запросе, если вы принудительно не сделаете сортировку. Например, в варианте, который я привёл со склейкой по номерам строк, номера строк назначаются произвольно. Строгий порядок будет, если в over() добавить сортировку, допустим по item вида over(order by item)....но то ли это, что вам надо? Вот все и интересуются на свой лад)
Вам нужно просигнализировать базе на сервере Б, что в базе на сервере А вставилась строка с новыми данными. Это можно сделать или из базы сервера А, или из приложения/очереди сообщений, осуществляющего вставку в базу сервера А. В любом случае надо лезть или в базу сервера А, или в то, что в неё пишет. Есть, конечно, вариант на сервер Б подключить в виде внешней таблицы таблицу сервера А и по планировщику крутить какой-то запрос вида "есть ли чего новенького?", но это дикое порно и оверхед. Даже не рассматривайте. Насчёт решения Евгений Вольф - я не помню, можно ли писать через внешние таблицы. Нужно посмотреть в документации. Если можно, то его решение вам подходит.
Да, я пробовал этот вариант. Но это лишний оверхед - получится, что я строю пятый рейд из iscsi, отрезанных от NAS с пятыми рейдами. Плюс я теряю место. Ну и еще минус - если один из iscsi дисков рейда стал недоступен из-за проблем сети/питания, то при его возвращении в рейд, рейд придется пересобирать. Это очень больно, долго и вообще порочно.
Насчет "убедить систему, что размер диска равен нулю"... мда, пробелы в базовых знаниях никогда ни к чему хорошему не приводили. При монтировании iscsi в точку монтирования корневой системы, точка монтирования получает свою таблицу inodes, в которой содержатся сами inodes (тупо id) файлов и их атрибуты (в том числе и размер). По ним и считается свободное место на iscsi. Поэтому, когда связь с физическим iscsi теряется, таблица inodes никуда из точки монтирования не делась и размер все еще определяется как на момент потери связи. Так что mergerfs порой будет уходить в read only при потери связи с iscsi с самым большим свободным местом, тут ничего не поделать. Всяко это будет редко, да и перемонитировать - пара пустяков в случае сбоя.
Нет, zfs не пробовал ставить (вроде Ubuntu 16.04 его должна уметь из репозитория). Сколь я смотрел, zfs может собирать аналоги raid'ов своими средствами. Рейды с избыточностью хранения мне не нужны - iscsi нарезаны на NAS, где уже raid5. По факту мне нужна union файловая система, а не raid или jbod. zfs могла бы мне дать аналог raid1, но при вылете одного из iscsi дисков (в серверной с NAS этого iscsi что-то случилось) я теряю весь массив. А при union-like файловой системе, я перехожу в read-only или продолжаю работать со всеми данными, кроме тех, которые на вылетевшем NAS. Хотя я могу не правильно понимать zfs, я ее еще руками не пробовал. Если не прав, поправьте, пожалуйста!
Нет, к сожалению такой вариант не сработает. PACS представляет из себя службу, слушающую порт, базу данных и некую точку монтирования, куда помещаются прилетевшие dicom снимки. dicom снимок - это контейнер с тегами (имя человека, на каком аппарате сделано и т.д.) и содержимым (серии фотографий, видео и т.д.). Когда такой снимок прилетает на службу PACS, PACS сам решает, куда положить на точке монтирования снимок и индексирует его теги и путь хранения в БД. Я использую Orthanc, он опенсорсный и поддерживает lua скрипты внутри. Но я сильно сомневаюсь, что они позволяют проверять доступность файловой системы перед записью и корректно обрабатывать исключение. А если и могут, то это очень мудреный вариант, я бы хотел его избежать))) А просто демон не подойдет, адрес, куда будет сохранен файл определяет PACS и перед этим кладет его в индекс в БД. Если демон его переместит, PACS потом не найдет снимок.
За Java платят больше денег, это точно)) Хотя Python красивее, изящнее и компактнее. Плюс позволяет куда проще реализовывать различные паттерны (а часть так и вовсе не нужна из-за отсутствия типов). Но вот и отстрелить себе ногу позволит на раз два по описанным выше причинам, это да.
Не переживай, эти вещи ты узнаешь в реальной работе. У меня это заняло три с половиной года, но счастья или денег не принесло. Если бы сейчас начинал заново, пошел бы в мобильную разработку)) А PHP ты бросай, ну его, оно темное и злое.
Концептуально enum - самый правильный вариант для перечислений небольшого размера или чьи значения должны участвовать в коде функций. плюс не нужна дополнительная таблица с перечнем полов человека.Так что берите его, не пожалеете.
Написано
Войдите на сайт
Чтобы задать вопрос и получить на него квалифицированный ответ.
