И если вы создадите таблицу организаций, в которой укажите поле родителя, то вам тоже придётся для построения всех зависимостей обратиться к таблице деревянным запросом
вы точно изучили теорию перед проектированием структуры данных? Nested sets и subsets не требуют рекурсивных запросов при построении, но да, сложнее в управлении и кодинге, чем наивное представление дерева через список смежности и уж точно эффективнее построения чего угодно с table access full и фильтрацией по строковому шаблону (тоже не самая дешёвая операция, между прочим).
Вообще статья вызвала ностальгию, вспомнилось хождение по граблям со справочниками в 2002-2008 годах. Пока что вы идёте ровно по тому же маршруту.
Модель данных Adjacency List для представления иерархии именно что оптимизирована на запись в ущерб чтению — простая и интуитивно понятная модификация иерархии, но построение иерархии из таблиц в такой модели данных требует рекурсивных запросов, которые изрядно грузят CPU.
1. Никогда, ни за что, ни в коем случае не используйтё EAV для создания системы управления НСИ. Сразу вспоминается пара лет, убитых на то, чтобы уйти с такой модели данных, когда упёрлись в полное отсутствие масштабируемости такого решения, а оно было растиражировано в дюжину систем у множества заказчиков, уже работавших в проде.
2. Что за стремление использовать при проектировании системы, нагрузка на чтение в которой на 2-3 порядка выше, чем нагрузка на запись (а почти любая система управления НСИ такова), использовать структуры данных, оптимизированные для быстрой записи, но создающие абсолютно неадекватную нагрузку при чтении?
3. Использование конструкций вида
v_log_query := 'SELECT ''' || :NEW.surname || ''' AS surname, ''' || :NEW.name || ''' AS name, ''' || :NEW.patronymic || ''' AS patronymic, to_date(''' || :NEW.birthday || ''', ''dd.mm.yy'') AS birthday FROM DUAL'
для динамического SQL в Oracle это прям кровь из глаз и верный способ завалить собеседование и обратить на себя гнев DBA. Не надо так. Use bind variables, Luke!
Вам бы ещё поддержку оракловых SYS пакетов довести до ума (DBMS_… и вот это всё), чтобы работало без получасовой интроспекции системных схем и пляски с бубном при настройке областей видимости.
Кстати, по опыту эксплуатации я своё мнение поменял. Тот же БП на 650Вт при нагрузке в 400-500Вт начинает греться и гудеть кулером как не в себя — сейчас при средних нагрузках БП шумит ощутимо громче остальной системы, а например Seasonic на 1000Вт при нагрузках до 500Вт вообще работает в пассивном режиме.
попытка эксплуатации ноутбука образца 2009 года на Athlon x2 QL-64/4GB RAM/SSD после чистой установки сборки Windows 10 1809 провалилась — после каждой перезагрузки система уходила в себя минут на 10 со 100% загрузкой CPU от всяких обновляторов и antimalware executable и в это время имела околонулевую отзывчивость, притом эта активность периодически возникала ещё и после перезагрузки в рандомные промежутки времени. На более старых сборках таких острых проблем не возникало. При этом в драйверах 10-ки выпилили поддержку DXVA.
Откат на Windows 8.1 все проблемы решил — отзывчивость системы вернулась к норме и в качестве печатной машинки/браузера ноут стал работать нормально. И аппаратный декодер видео вполне себе заработал.
Так что всё же системы изрядно жиреют и требования к процессору и памяти потихоньку растут.
Если вынести за скобки лицензионные ограничения, судя по сайту производителя официально на этой модели ноутбука поддерживается Windows 8.1 и для неё есть драйвера. По моему опыту, Windows 8.1, особенно в версии LTSB, заметно меньше грузит фоновыми процессами слабое железо. Скорее всего и сама она легче, и обновления на пару гигабайт ей уже не грозят.
На древнем ноуте ASUS K50AB с Athlon QL64 на борту, 8.1 обеспечивала вполне комфортную работу, а 10 — регулярно уходила на пол часа в себя и не всегда оттуда возвращалась.
ничуть. просто на версии биоса 5007 вообще не работали лимиты потребления. Как только они заработали — всё встало на свои места. Можете результаты глянуть в обновлении статьи, я добавил результаты тестов на нормальной прошивке с работающими лимитами.
ничуть. после нескольких сборок-разборок плотно упакованного тетриса в корпусе MicroATX плюнуть на компактность и собрать систему в просторном Full Tower доставило огромное удовольствие.
конечно больше. 32MB кэша третьего уровня на 3700x против 16MB на 2700x, в два раза более широкая Infinity Fabric, полноскоростной AVX и прочие допилы явно не бесплатные по транзисторному бюджету. Притом там спеки вроде не совсем точные — кэш первого уровня у новых Ryzen не 96, а 64 килобайта.
При этом греется он куда сильнее 2700х. Судя по всему, проблемы те же, что и у Intel при уменьшении размера кристалла при переходе на более тонкий техпроцесс — тепло теперь нужно отводить с гораздо меньшей площади, чем раньше.
Даунвольт пробовал, любое снижение сразу уменьшает малопоточный буст на 25-50Mhz, хотя и чуть снижает температуры под полной нагрузкой. 2700x у меня вообще работал под оффсетом -0.08125В, и горя не знал, удачный был экземпляр, с имеющимся у меня на руках экземпляром 3700x такой номер не прошёл.
С другой стороны материнка обеспечивает спокойно 200+ Вт питания без перегрева, Prime95 гонял где-то сутки на 2700х с потреблением как раз до 200 доходившим, даже 70 градусов там не было — корпус с парой 200мм вертушек на верхнем выдуве обеспечивает отличный обдув материнки в тч и с тыльной стороны.
А при чем здесь поколения матерей? Топология может ограничивать максимально достижимые частоты и/или тайминги, но на скорость работы при прочих равных не влияет от слова никак. В конце концов посмотрите тесты на х570 — в них результаты точно такие же, и просадка записи, и падение общих скоростей
вы точно изучили теорию перед проектированием структуры данных? Nested sets и subsets не требуют рекурсивных запросов при построении, но да, сложнее в управлении и кодинге, чем наивное представление дерева через список смежности и уж точно эффективнее построения чего угодно с table access full и фильтрацией по строковому шаблону (тоже не самая дешёвая операция, между прочим).
Вообще статья вызвала ностальгию, вспомнилось хождение по граблям со справочниками в 2002-2008 годах. Пока что вы идёте ровно по тому же маршруту.
2. Что за стремление использовать при проектировании системы, нагрузка на чтение в которой на 2-3 порядка выше, чем нагрузка на запись (а почти любая система управления НСИ такова), использовать структуры данных, оптимизированные для быстрой записи, но создающие абсолютно неадекватную нагрузку при чтении?
3. Использование конструкций вида
для динамического SQL в Oracle это прям кровь из глаз и верный способ завалить собеседование и обратить на себя гнев DBA. Не надо так. Use bind variables, Luke!
Откат на Windows 8.1 все проблемы решил — отзывчивость системы вернулась к норме и в качестве печатной машинки/браузера ноут стал работать нормально. И аппаратный декодер видео вполне себе заработал.
Так что всё же системы изрядно жиреют и требования к процессору и памяти потихоньку растут.
На древнем ноуте ASUS K50AB с Athlon QL64 на борту, 8.1 обеспечивала вполне комфортную работу, а 10 — регулярно уходила на пол часа в себя и не всегда оттуда возвращалась.
При этом греется он куда сильнее 2700х. Судя по всему, проблемы те же, что и у Intel при уменьшении размера кристалла при переходе на более тонкий техпроцесс — тепло теперь нужно отводить с гораздо меньшей площади, чем раньше.
Вот тут хороший гайд по настройке памяти на платформе AM4: www.overclockers.ua/memory/amd-ryzen-memory-overclocking
С другой стороны материнка обеспечивает спокойно 200+ Вт питания без перегрева, Prime95 гонял где-то сутки на 2700х с потреблением как раз до 200 доходившим, даже 70 градусов там не было — корпус с парой 200мм вертушек на верхнем выдуве обеспечивает отличный обдув материнки в тч и с тыльной стороны.
Есть. По идее, достаточно отключить XFR и/или PBO.
А при чем здесь поколения матерей? Топология может ограничивать максимально достижимые частоты и/или тайминги, но на скорость работы при прочих равных не влияет от слова никак. В конце концов посмотрите тесты на х570 — в них результаты точно такие же, и просадка записи, и падение общих скоростей
Ну да, южный мост конечно 'очень важен' при работе с памятью, когда топология матери daisy chain и контроллер памяти в CPU.
Вы уверены, что вы планки вставляли в разные каналы? Просто симптомы уж очень напоминают использование двух планок в одном канале