И запрос select * from t1 начинает возвращать столбцы в другом порядке - так, как select c, a, b from t1. Обратная совместимость потеряна, приложение сломано.
Ни одна нормальная РСУБД не гарантирует порядок полей и порядок строк при возвращении. Если программист надеется на это - то он сам себе злобный буратино, не знающий ничего про реляционную алгебру.
Что бы удалить миллиард строк, надо записать миллиард строк в индекс, а потом удалить этот же миллиард строк из индекса. А кроме того, ещё и индексы к таблице есть. И, по-хорошему, там тоже надо отдельную сущность инспектора на каждый индекс.
И, если я не ошибаюсь, в СУБД, которые работают на основе блокировок, всё это так и выглядит - есть структура в памяти, в которой учитываются блокировки строк, страниц, экстентов, таблиц, индексов, объектов и базы данных.
И что если стоит, но поступила такая информация - затирать ли предыдущую? Не записывать? Что ж вы меня спрашиваете? Спросите лучше архитектора вашей модели данных.
Собственно, якорное моделирование данных - это 6NF, судя по статье в википедии. Поэтому нет никакого противоречия между РСУБД и якорными БД. Данные якорной модели хранятся в нескольких таблицах в РСУБД по факту.
Я существенную разницу не увидел когда погонял на Linux , структура процессов и хранения одинакова, разницы в производительности не заментно.
Мой опыт говорит об обратном: разница при работе 1с с PG на Windows и Linux существенна. Жалобы на медленную работу 1с при переносе сервера БД на линукс пропадают. Возможно, это всё зависит от других вещей, например - расположения на одном сервере сервисов приложения и БД. Но при этом исчерпания ресурсов не было замечено.
Тот же Дорошкевич Антон говорил на пгконфе, что использование ПГ на виндовс в составе 1с возможно для небольшого количества клиентов, по-моему, до 15.
По факту, PG для работы использует вызов fork, который в Windows приходится эмулировать.
Также, при работе в Windows вы теряете возможности: например JIT компиляцию, использование расширений. Тот же pbk больше не поддерживается в Windows.
для 1С мне доступны только два бесплатных варианта Postgres это сборка от 1С и PostgresPro (базовая) но ни в той ни другой там pg_prodbackup нет. Есть только в платных PostgresPro
pg_probackup бесплатен, и устанавливается из обычного репозитория. Ничего не надо собирать для популярных, в том числе и импортозамещённых. дистрибутивов.
Я бы не сказал, что этажные МФУ - большие. Равно, как бы и то, что ниша использования этого ПО - узкая. Скорее - наоборот, судя по высокой конкуренции в области печати по требованию. Маржинальность этого рынка больше, чем рынка печати для soho.
Разумеется, нет смысла городить Follow printing в компании из пяти человек и одного принтера, но начиная с определённого момента роста размера компании, приобретение данного ПО становится выгодным, хотя бы за счёт экономии на бумаге.
Кстати, иметь один этажный принтер выгоднее со всех сторон, чем россыпь локальных.
С другой стороны, соорудить подобную систему на базе сервера печати Windows не так уж и сложно. Ведь, по сути, опубликованные принтеры - это сетевые шары, куда можно просто скопировать сформированный PCL\PS\PDF (в зависимости от принтера) файл из БД, по запросу от нужного устройства.
Ну, идеальным решением стало бы follow printing, когда в ОС устанавливается только один виртуальный принтер, а печать определяется политиками организации. Вот тут, к примеру, статья у КРОК с описанием преимуществ.
Всё же проще устанавливать опубликованные в АД принтеры через gpo\Политики пользователя\предпочтения, с нацеливанием на вхождение пользователя в определённую доменную группу. Для автоматической установки достаточно включения в доменную группу и релогин пользователя.
Вот, кстати, пилят неплохую штуку: Тантор Платформа. Туда интегрировали аналайзер запросов от Тензора.
Обещают выпустить бесплатную версию, но пока не определились с политикой. Вполне возможно или выпустят в урезанном виде, или с ограничением по лицензиям.
В случае приобретения лицензии на СУБД Тантор (это форк postgresql) Платформа отдаётся бесплатно.
https://github.com/postgrespro/pg_pathman
удобнее и функциональнее pg_partman, но устанавливается без танцев с бубном только на семейство СУБД PGPro.
Ни одна нормальная РСУБД не гарантирует порядок полей и порядок строк при возвращении. Если программист надеется на это - то он сам себе злобный буратино, не знающий ничего про реляционную алгебру.
Уже было.
Питер Уоттс «Ложная слепота»
Что бы удалить миллиард строк, надо записать миллиард строк в индекс, а потом удалить этот же миллиард строк из индекса.
А кроме того, ещё и индексы к таблице есть. И, по-хорошему, там тоже надо отдельную сущность инспектора на каждый индекс.
И, если я не ошибаюсь, в СУБД, которые работают на основе блокировок, всё это так и выглядит - есть структура в памяти, в которой учитываются блокировки строк, страниц, экстентов, таблиц, индексов, объектов и базы данных.
Технически, если в вашем хранилище нет ничего чувствительного, можно ограничиться github/gitlab etc.
Всё становится ещё проще.
Вроде Another World тоже
Собственно, якорное моделирование данных - это 6NF, судя по статье в википедии. Поэтому нет никакого противоречия между РСУБД и якорными БД. Данные якорной модели хранятся в нескольких таблицах в РСУБД по факту.
В любой нормальной (в обоих смыслах) реляционной БД такое не случается. Ибо нормализация как раз и направлена на недопущение таких вот моментов.
Думаю, что стоит привести высказывание К. Дж. Дейта:
"База данных в действительности - это множество истинных высказываний"
Надо понять работу РСУБД, начиная с ACI(D), и многие вещи перестанут быть бредом.
Мой опыт говорит об обратном: разница при работе 1с с PG на Windows и Linux существенна. Жалобы на медленную работу 1с при переносе сервера БД на линукс пропадают. Возможно, это всё зависит от других вещей, например - расположения на одном сервере сервисов приложения и БД. Но при этом исчерпания ресурсов не было замечено.
Тот же Дорошкевич Антон говорил на пгконфе, что использование ПГ на виндовс в составе 1с возможно для небольшого количества клиентов, по-моему, до 15.
По факту, PG для работы использует вызов fork, который в Windows приходится эмулировать.
Также, при работе в Windows вы теряете возможности: например JIT компиляцию, использование расширений. Тот же pbk больше не поддерживается в Windows.
pg_probackup бесплатен, и устанавливается из обычного репозитория. Ничего не надо собирать для популярных, в том числе и импортозамещённых. дистрибутивов.
Откройте для себя pg_probackup
Просто, надёжно, удобно.
И перестаньте использовать Windows для PG, пожалуйста.
Оставлю это тут:
https://habr.com/ru/articles/136401/
Присоединяюсь к вопросу - кто такой Фёдор?
Самая большая интрига в статье -- этот Фёдор
А можно ещё использовать триггеры FSRM и не крутить электросчётчик вечным циклом :)
Парни из PostgresPro смогли. )
Я бы не сказал, что этажные МФУ - большие. Равно, как бы и то, что ниша использования этого ПО - узкая.
Скорее - наоборот, судя по высокой конкуренции в области печати по требованию. Маржинальность этого рынка больше, чем рынка печати для soho.
Разумеется, нет смысла городить Follow printing в компании из пяти человек и одного принтера, но начиная с определённого момента роста размера компании, приобретение данного ПО становится выгодным, хотя бы за счёт экономии на бумаге.
Кстати, иметь один этажный принтер выгоднее со всех сторон, чем россыпь локальных.
С другой стороны, соорудить подобную систему на базе сервера печати Windows не так уж и сложно. Ведь, по сути, опубликованные принтеры - это сетевые шары, куда можно просто скопировать сформированный PCL\PS\PDF (в зависимости от принтера) файл из БД, по запросу от нужного устройства.
Ну, идеальным решением стало бы follow printing, когда в ОС устанавливается только один виртуальный принтер, а печать определяется политиками организации.
Вот тут, к примеру, статья у КРОК с описанием преимуществ.
Всё же проще устанавливать опубликованные в АД принтеры через gpo\Политики пользователя\предпочтения, с нацеливанием на вхождение пользователя в определённую доменную группу.
Для автоматической установки достаточно включения в доменную группу и релогин пользователя.
Вот, кстати, пилят неплохую штуку: Тантор Платформа.
Туда интегрировали аналайзер запросов от Тензора.
Обещают выпустить бесплатную версию, но пока не определились с политикой. Вполне возможно или выпустят в урезанном виде, или с ограничением по лицензиям.
В случае приобретения лицензии на СУБД Тантор (это форк postgresql) Платформа отдаётся бесплатно.