Логику приложения это точно не усложняет (это не триггеры, которые влияют на данные).
Это экономит ресурсы: размер таблицы на диске (за который тут в статье боролись), CPU, и самое главное io диска. Да ещё и вакуум, который тоже сожрёт процессор и io диска.
>по факту нужно помнить, что есть триггер и проапдейтится только то, что нужно
Менять значение только там, где его надо поменять это правильно, но делать это условием WHERE может оказать очень дорого (банально нет индекса по этому полю). Поэтому лучше пользоваться встроенным системным триггером, который такие обновления подавляет (suppress_redundant_updates_trigger https://www.postgresql.org/docs/16/functions-trigger.html). Из «недостатков» в ответ на попытку изменить значение на то же самое, в ответ придёт 0 rows affected. Это если принимать во внимание комментарий выше, где приложение ломается от перестановки полей.
Для красоты, писать условия для булевых полей можно явно:
Японский ламинат тем и хорош: снаружи пластичная сталь, а внутри твёрдая. Устал от крошащейся кромки немецких, теперь сплошное удовольствие.
Правлю раз в неделю, раз в полгода могу на камнях заморочиться с выставлением углов в попытках привести нож в заводское состояние. Из недостатков – сталь высокоуглеродистая, поэтому легко ржавеет.
Для материализованного пути используйте расширение LTREE и соответствующие индексы, тогда можно будет искать не только по префиксу, и по вхождению и наименьшего общего родителя и много чего ещё.
Да, сложно. Во времена версий PostgreSQL 9.4 я себя буквально заставил. Ни разу не пожалел.
Главным толчком послужила попытка поставить на нетбук с Atom на борту, "лёгкий" SQL Server Express. После 4-х часов установки, я понял, что даже в случае успеха, перестановка и трабл шутинг могут занять бесконечное время. И попробовал поставить PostgreSQL. Установка заняла 3 минуты. Таких стендов предполагалось сотня, выбор был очевиден.
В терминах PostgreSQL: если вам не надо сравнивать значения (больше/меньше) находить диапазоны, вам нужен TEXT. Быстро находить поможет индекс построенный, например, по регулярке.
С любой местной разработкой (если это именно разработка, а не запланированное кидалово) ситуация одинаковая: она нужна вне зависимости от того, насколько она отстаёт и "сколько водителей можно нанять за эти деньги".
Просто потому, что если разработки не будет, вы так и будете продолжать нанимать водителей. А вот если начать делать, то сначала она будет отставать, и будет дорогая, но в конечном итоге вы получите своё решение, опыт (который невозможно купить даже с технологиями), и, возможно, продукт на продажу.
Но самое главное, это независимость от поставщика технологий. Поэтому китайцам наплевать на то, что техпроцесс в чипах у них 7нм, а не 5нм (или 5нм, а не 3нм), пусть это будет откат на 3 года, своё гораздо важнее.
2 года (LG OLED65C1RLA) сразу решил, что пользоваться буду без оглядки на технологию, запретил всякие понижения яркостей после долгой работы и прочие ЭКО режимы. Никакой деградации в цветах не вижу и всё так же радует бесконечным контрастом.
Из "недостатков" то же, о чём написано у вас – падение яркости при большом количестве белого.
Ни одного примера, ни одной технической подробности и сравнения было-стало. В начале статьи "замена СУБД", а потом сразу "только если это кэш система и структура не статична".
Наша система построена на основе графов, и хранение таких графов в классической СУБД представляет собой сложную задачу...
Рекуператор торможения был ещё в первом Тойота приус, 1997 года выпуска. Это серийный автомобиль, не то что формула 1. Аккумуляторы там были никель-металл-гидридные, а не литий-ионные.
Вот это действительно долгожданная новость.
Очень интересно, спасибо. Интересуюсь такого рода железками, правда для плавания на лодке.
Ссылки на компоненты/софт/3д-модел были бы очень кстати.
Логику приложения это точно не усложняет (это не триггеры, которые влияют на данные).
Это экономит ресурсы: размер таблицы на диске (за который тут в статье боролись), CPU, и самое главное io диска. Да ещё и вакуум, который тоже сожрёт процессор и io диска.
>по факту нужно помнить, что есть триггер и проапдейтится только то, что нужно
Зачем это помнить? Надуманные проблемы.
Менять значение только там, где его надо поменять это правильно, но делать это условием WHERE может оказать очень дорого (банально нет индекса по этому полю). Поэтому лучше пользоваться встроенным системным триггером, который такие обновления подавляет (suppress_redundant_updates_trigger https://www.postgresql.org/docs/16/functions-trigger.html). Из «недостатков» в ответ на попытку изменить значение на то же самое, в ответ придёт 0 rows affected. Это если принимать во внимание комментарий выше, где приложение ломается от перестановки полей.
Для красоты, писать условия для булевых полей можно явно:
Какие-то zwilling, муссатом (с вертикальными насечками) их править не смог, выщерблены убирал на заточном станке c мокрым камнем (а-ля torkwerk).
Японский ламинат тем и хорош: снаружи пластичная сталь, а внутри твёрдая. Устал от крошащейся кромки немецких, теперь сплошное удовольствие.
Правлю раз в неделю, раз в полгода могу на камнях заморочиться с выставлением углов в попытках привести нож в заводское состояние. Из недостатков – сталь высокоуглеродистая, поэтому легко ржавеет.
Для материализованного пути используйте расширение LTREE и соответствующие индексы, тогда можно будет искать не только по префиксу, и по вхождению и наименьшего общего родителя и много чего ещё.
Да, сложно. Во времена версий PostgreSQL 9.4 я себя буквально заставил. Ни разу не пожалел.
Главным толчком послужила попытка поставить на нетбук с Atom на борту, "лёгкий" SQL Server Express. После 4-х часов установки, я понял, что даже в случае успеха, перестановка и трабл шутинг могут занять бесконечное время. И попробовал поставить PostgreSQL. Установка заняла 3 минуты. Таких стендов предполагалось сотня, выбор был очевиден.
Байтики экономите?
В терминах PostgreSQL: если вам не надо сравнивать значения (больше/меньше) находить диапазоны, вам нужен TEXT. Быстро находить поможет индекс построенный, например, по регулярке.
С любой местной разработкой (если это именно разработка, а не запланированное кидалово) ситуация одинаковая: она нужна вне зависимости от того, насколько она отстаёт и "сколько водителей можно нанять за эти деньги".
Просто потому, что если разработки не будет, вы так и будете продолжать нанимать водителей. А вот если начать делать, то сначала она будет отставать, и будет дорогая, но в конечном итоге вы получите своё решение, опыт (который невозможно купить даже с технологиями), и, возможно, продукт на продажу.
Но самое главное, это независимость от поставщика технологий. Поэтому китайцам наплевать на то, что техпроцесс в чипах у них 7нм, а не 5нм (или 5нм, а не 3нм), пусть это будет откат на 3 года, своё гораздо важнее.
Большая часть патентных заявок касается сборки и склеивания различных частей экрана
стеклянный экран для вай-фаев и прочих блютусов будет прозрачен, это хорошо.
Ещё чуть-чуть и вспомнят что есть LaTeX, и тебе шаблоны и тебе вёрстка качественная и тебе PDF из коробки.
2 года (LG OLED65C1RLA) сразу решил, что пользоваться буду без оглядки на технологию, запретил всякие понижения яркостей после долгой работы и прочие ЭКО режимы. Никакой деградации в цветах не вижу и всё так же радует бесконечным контрастом.
Из "недостатков" то же, о чём написано у вас – падение яркости при большом количестве белого.
Большое спасибо за обзор. Давно сижу за 43“ мониторами IPS и потребности очень схожи с вашими (power delivery, USB-c и так далее).
Телевизор как раз OLED, как раз LG, поэтому попали в самое сердечко.
А можно машину таким покрыть?
Ни одного примера, ни одной технической подробности и сравнения было-стало. В начале статьи "замена СУБД", а потом сразу "только если это кэш система и структура не статична".
Как именно хранили? Метрики? Что стало?
Вот тут человек регулярно собирает под новые версии https://vvs.ru/pg/
И вот тут https://github.com/levinsv/pgadmin3
Рекуператор торможения был ещё в первом Тойота приус, 1997 года выпуска. Это серийный автомобиль, не то что формула 1. Аккумуляторы там были никель-металл-гидридные, а не литий-ионные.
Помню первый раз, когда перешёл по гиперссылке, это был текстовый браузер в терминале VAX VMS, звали его lynx.