Его крокейшество о вредности СУБД, если архитектурно она для программ, а не живого человека

А вот при попытке записать в SQL эти байты могут испортиться…

Не понимаю каким образом.

У вас в библиотеке для подключения к БД (условном libpq++) идет какое-то перекодирование?

выбрали наихудший - ибо 2 номера наворачивает логику - как приотизировать поля какие из 4 вариантов возможно и прочая хурма

При чём тут приоритезация? В карточке клиента два поля «Телефон1» и «Телефон2». Как при добавлении новости на ЛОР есть поля «Дополнительное изображение #0», «Дополнительное изображение #1», «Дополнительное изображение #2». Как думаешь, там три поля в базе или массив или дополнительная таблица?

вот для сохранения уровня дискиссии

всёж повторно рекомендую (повторно?) сломать мозг

по различию уровень представления и уровень приложения в старых теориях у Дейты ( там ещё уровень хранения - и как раз попытка изолировать абкакции )

имхо плодить поля(однородные) в отношении обычно худший вариант из возможных

тем более современный sql позволяет авто-паковать(распаковывать) однородности в одно поле"массив"

ваще чем больше кривых решений тем дороже квалифицированный труд :)

чуть чуть становится понятней тейк Croco

У вас в библиотеке для подключения к БД (условном libpq++) идет какое-то перекодирование?

Да, согласен, он просто не сохраняет.

Insert into table failed: ERROR: invalid byte sequence for encoding «UTF8»

ваще пример inode fs первоуниха

подсказывает решение

вот есть два поля телефонов - некоторого типа (хз чисто текст с нормализацией при внесении али просто raw с прелестями постобработки; али числа с паразитным ненулём в нужной степени :) )

для сохранения старых ошибок стоит добавить одно поле - «остальные номера» и там с разделителем(ТМ)(но лучше с завершителем) ноль и более телефонов**

с «постепенным» переходом к случаю

двух полей - номер

и второе поле остальные номера

Тут все-таки вопрос откуда в исходной строке внутри C++ного кода возьмутся некорректные UTF-8 последовательности. Либо это баг в коде, например, неправильная модификация строки, либо левые данные были получены без проверки из внешнего источника.

От обоих этих случаев, имхо, самодельные строки просто так не защитят.

При чём тут приоритезация

в смысле логики - в практике возможно 3 случая от 0 до 2 номеров

при размазывания на два поля 4 случая ; приводящая либо к багам либо к дополнительным преседания сводящим 2 случая 10 и 01 к случаю один-номер

ваще это хорошо что люди творят

Тут все-таки вопрос откуда в исходной строке внутри C++ного кода возьмутся некорректные UTF-8 последовательности. Либо это баг в коде, например, неправильная модификация строки, либо левые данные были получены без проверки из внешнего источника.

Я же написал. В С++ std::string это любая последовательность байтов, а не строка UTF-8. Там может быть строка в другой кодировке. Или вообще встроенная картинка в каком-нибудь формате. Багом оно становится только при записи в SQL.

Например, программа обрабатывает файлы. Имя файла в Linux может содержать любые байты кроме «/» и «\0». В std::string имя файла читается, а в SQL уже не всегда.

Я же написал. В С++ std::string это любая последовательность байтов, а не строка UTF-8. Там может быть строка в другой кодировке.

Просто так не может.

Вы свои исходники держите в UTF-8. В случае VC++ компилируетесь так, чтобы и в исполнимом файле все было в UTF-8, а под Linux-ом на эту тему и париться не нужно.

Следовательно в коде у вас не может быть текстовых строк вне UTF-8, если только вы:

• не допустили ошибку при манипуляции своими строками;
• не прочитали данные из внешнего источника без валидации.

Или вообще встроенная картинка в каком-нибудь формате.

Это означает проблему в вашем коде – вы смешиваете std::string-и с текстом с std::string-ами с бинарными данными.

В std::string имя файла читается, а в SQL уже не всегда.

Т.е. вы хотите сказать, что в Linux-е можно получить имя файла в некорректном UTF-8 представлении?

И в чем проблема? Если хочешь хранить бинарные данные, то храни их как бинарные. В том же постгресе это bytea, в прочих БД могут быть другие варианты.

Вы свои исходники держите в UTF-8. В случае VC++ компилируетесь так, чтобы и в исполнимом файле все было в UTF-8, а под Linux-ом на эту тему и париться не нужно.

При чём тут исходники? Большинство программ работают с внешними данными: файлами, именами файлов, байтами из Сети…

В UTF-8 гарантированно можно загнать только пользовательский ввод.

Это означает проблему в вашем коде – вы смешиваете std::string-и с текстом с std::string-ами с бинарными данными

В коде проблемы нет. Есть проблема записать std::string с бинарными данными в SQL.

Т.е. вы хотите сказать, что в Linux-е можно получить имя файла в некорректном UTF-8 представлении?

Конечно. Кодировка определяется пользователем, а не файловой системой.

В том же постгресе это bytea, в прочих БД могут быть другие варианты

И сразу же перестаёт работать индексация, насколько я понимаю.

При чём тут исходники? Большинство программ работают с внешними данными: файлами, именами файлов, байтами из Сети…

При том, что у вас только два источника для строк в программе – либо литералы внутри, либо данные снаружи.

И если с данными внутри все OK при нормальной сборке проекта, то вопрос остается только с данными снаружи. Которые должны валидироваться, если мы имеем дело с текстом в UTF-8.

Есть проблема записать std::string с бинарными данными в SQL.

SQL-СУБД перестали поддерживать BLOB-ы?

Кодировка определяется пользователем, а не файловой системой.

Прекрасно. Допустим, ваша программа пишет логи в UTF-8 и должна записать туда имя этого файла. Или должна сформировать JSON с именем этого файла внутри.

Чем это отличается от записи в СУБД?

Которые должны валидироваться, если мы имеем дело с текстом в UTF-8.

И которые по сути задачи не обязаны быть текстом.

SQL-СУБД перестали поддерживать BLOB-ы?

Для BLOB’ов SQL не умеет ни сортировку, ни индексы ни внешние ключи… Вроде даже поиск по содержимому не умеет.

Допустим, ваша программа пишет логи в UTF-8 и должна записать туда имя этого файла.

Если логи ограничены UTF-8, то имя будет закодировано в какой-нибудь base64.

Если логи ограничены UTF-8, то имя будет закодировано в какой-нибудь base64.

Но логи обычно не ограничивают какой-то кодировкой (я такого не видел).

Нет, можно делать индекс как по этому bytea, так и по expression (например, по decode этого индекса в utf-8 с replace инвалидных вещей). bytea — это буквально raw string для постгреса, есть ограничения только на локалеспецифичные операции (потому, что у массива байт нет локали).

С сортировкой сложнее, но сортировка мусора без кодировки это изначально не определенная операция. На практике можно сделать generated column с попыткой декодировать это все в нормальную юникодную строку (convert_from + decode с escape там) и сортировать по нему.

Постгрес умеет и индексы, и ключи, и поиск, но операциями для блобов (вроде position), а не для строк. Для локалеспецифичной сортировки нужно будет вытаскивать строку из блоба с либо игнором, либо escape/replace инвалидного юникода. Эту строку можно вытаскивать + сортировать в отдельный generated column либо на лету.

В С++ std::string это любая последовательность байтов

Для бинарных данных (которые в С++ по ошибке назвали «string») в sql надо использовать не типы вроде text, а типы вроде blob.

Его крокейшество не понимает, что главное в СУБД - это вовсе не SQL, а вещи вроде кластеризации, писания бэкапов, и вот этого всего. А в современное время - ещё и интеграция со всякими ZNS. И если ты начнёшь пилить все это самостоятельно, то получишь ту же СУБД. Только самопальную и вероятно с кучей багов и уязвимостей, которую тебе к тому же придётся самостоятельно поддерживать.

Ладно. Похоже, постгрес по сравнению с «обычным SQL» заметно продвинулся.

Посмотрел, действительно есть и подстроки из блоба и индексы по выражению.

А вы сможете сформулировать для постгреса запрос «получить все записи относящиеся к последним 5 дням, по которым есть хотя бы одна запись»?

И даже рациональные числа в постгрес, оказывается, есть.

а вещи вроде кластеризации, писания бэкапов, и вот этого всего. А в современное время - ещё и интеграция со всякими ZNS

Вот если всё это надо, то верно.

Столяров про ситуацию, когда ставишь себе локальное прикладное приложение, а оно себе постгрес хочет.

PGSQL

CREATE TABLE logs (id SERIAL DEFAULT, event_time TIMESTAMP NOT NULL, message VARCHAR(1024) NOT NULL);


WITH days AS (
  SELECT DISTINCT event_time::date AS day
  FROM logs
  WHERE message IS NOT NULL AND btrim(message) <> ''
  ORDER BY day DESC
  LIMIT 7
)
SELECT *
FROM logs
WHERE event_time::date IN (SELECT day FROM days)
ORDER BY event_time DESC;

MySQL

CREATE TABLE logs (id INT PRIMARY KEY, event_time TIMESTAMP NOT NULL, message VARCHAR(1024) NOT NULL);


SELECT *
FROM logs
WHERE DATE(event_time) IN (
    SELECT day
    FROM (
        SELECT DATE(event_time) AS day
        FROM logs
        WHERE message IS NOT NULL AND TRIM(message) <> ''
        GROUP BY DATE(event_time)
        ORDER BY day DESC
        LIMIT 7
    ) AS t
)
ORDER BY event_time DESC;

Оптимизатор на SELECT DISTINCT event_time::date AS day ... ORDER BY day DESC LIMIT 7 сможет сообразить, что не надо читать всю таблицу?

Постгрес хорошо даже в локали, что мешает? Если мешает постоянный демон в фоне, можно duckdb или тот же sqlite.

Потому что «главное в СУБД - это вовсе не SQL, а вещи вроде кластеризации, писания бэкапов, и вот этого всего». А в локали оно всё не надо.

Мне просто было интересно как мои инструменты справятся с идентичной или аналогичной задачей. Мне ещё до сих пор не приходилось писать программу на C.

Хотя на Go приходилось разок, когда нужно было восстановить бэкап Windows 7. Я тогда не мог понять, что у меня текстовый редактор не поддерживает обработку нулевого байта и не всегда об этом кричит, поэтому от безысходности не мог найти другого выхода.

По поводу тормозных редакторов: zed обещает хорошую работу с большими файлами. Он там какую-то оптимизированную структуру данных использует. Сам не тестировал, но уже давно по-доброму завидую. У меня файлы в пару гигабайт открываются, но с ожиданием в полминуты.

ну ты бы duck db быб - оно ток мо локально бест в облахо есть другое (впрочем эквивалентное)

duckdb это реально вкусняшка

Если это одна и та же таблица, то просто запрос на «получить записи с датой >= сейчас - 5 дней и < сейчас» будет работать. «По которым есть хотя бы 1 запись» всегда TRUE для этих записей.

Если «по которым есть хотя бы одна запись» это отдельная таблица, то можно тем же WHERE EXISTS?

Если это одна и та же таблица, то просто запрос на «получить записи с датой >= сейчас - 5 дней и < сейчас» будет работать. «По которым есть хотя бы 1 запись» всегда TRUE для этих записей.

Нет. В таблице записи на 29.09, 26.09, 25.09, 23.09. А сейчас - 5 дней = 25.09.

не, ржавчина мне не нужна ни в каком виде. её у меня на машине нет и не будет. пусть ржавеют где-нибудь в другом месте :)

проблема открытия больших файлов в основном в мапировании, а не в «оптимизированных структурах».

проблема открытия больших файлов в основном в мапировании, а не в «оптимизированных структурах».

Проблема, что умение работать с данными, не помещающимися целиком в оперативную память, стало забытой технологией древних.

Умение работать с данными, которые помещаются в оперативную память — тоже утерянная технология.

скорее всего да, и это меня и удивляет. казалось бы, ничего сложного. ан-нет. на практике я вижу, что все редакторы пытаются зажрать весь файл в память. типа, виртуальной памяти много, давайте всё туда засунем.

The query optimizer takes LIMIT into account when generating query plans

https://geronimovelasco.medium.com/how-limit-and-offset-works-behind-the-scenes-in-postgresql-a09c2c063405

я бы еще индекс на event_time докинул, конечно

Древние тоже не умели. vi не умел.

я бы еще индекс на event_time докинул, конечно

Разумеется, предполагается, что индекс там есть.

The query optimizer takes LIMIT into account when generating query plans

Я про комбинацию с DISTINCT…

Столяров про ситуацию, когда ставишь себе локальное прикладное приложение, а оно себе постгрес хочет.

ни разу не видел, чтобы какое-то локальное приложение хотело себе постгрес. По ощущениям из тех, кому оно нужно, 95% промышляют sqlite. Вон тот же syncthing на него перешел. А sqlite ни пить ни есть не просит, лично у меня никогда с ним не было проблем.

ни разу не видел, чтобы какое-то локальное приложение хотело себе постгрес.

Аконади в кедах вроде мускуль хочет.

Не знаю можно ли считать GitLab локальным приложением, но он работает на постгресе.

Гитлаб веб-приложение.

Да и не локальное ни разу… Нет, можно, конечно, в докере пускать на локалхосте, но зачем?

ну вот akonadi. Либо mariadb, либо postgresql (опционально). Судя по репам арча, это единственное подобное. Я им никогда не пользовался, поэтому не знал. Все остальные с такой зависимостью - всякие серверные приложения, ну а на сервере иметь постгрес просто доктор прописал.

А.

CREATE TABLE logs (id SERIAL PRIMARY KEY, event_time TIMESTAMP NOT NULL, message TEXT NOT NULL);
CREATE INDEX logs_date ON logs(event_time);


INSERT INTO LOGS (event_time, message)
VALUES 
('2025-09-29', 'in range'), 
('2025-09-26', 'in range'),
('2025-09-25T01:00:00', 'in range'), 
('2025-09-09', 'out of range'),
('2025-09-25T02:00:00', 'in range'),
('2025-09-23', 'in range'),
('2025-09-22', 'in range');


WITH first_nonempty_date AS (
  SELECT day::timestamp AS day_ts FROM (
    SELECT DISTINCT event_time::date AS day
    FROM logs
    WHERE message IS NOT NULL AND btrim(message) <> ''
    ORDER BY day DESC
    LIMIT 5
  ) ORDER BY day ASC LIMIT 1
)
SELECT logs.*
FROM logs
JOIN first_nonempty_date ON TRUE
WHERE event_time >= first_nonempty_date.day_ts
ORDER BY event_time DESC;

Так?

Не, я помню ещё какая-то программулина была, которая требовала БД установленную. Только уже забыл, какая :)

Можно без докера запустить. Доступ к веб-интерфейсу через http://localhost.

К нему можно подключиться удалённо, если настроить сеть. Но с таким же успехом можно и к удалённому емаксу или вскоду подключиться, хотя это не веб-приложения.

Даже две. Amarok еще мускуль хотел раньше.

Устанешь ты его кирпичики без докера собирать и потом обновлять и саппортить, ты смотрел, чего там в контейнере напихано?

Вроде, довольно простая установка. Но обновлять и саппортить не пробовал, что там в контейнере — не смотрел. Если это оно, то выглядит как немного.

ни разу не видел, чтобы какое-то локальное приложение хотело себе постгрес.

https://kassa.bifit.ru/wiki/index.php?title=%D0%91%D0%98%D0%A4%D0%98%D0%A2_%D0%9A%D0%B0%D1%81%D1%81%D0%B0_Desktop_%D0%BF%D0%BE%D0%B4%D0%BA%D0%BB%D1%8E%D1%87%D0%B5%D0%BD%D0%B8%D0%B5_%D0%BA_PostgreSQL

https://github.com/glondu/nurpawiki/blob/master/doc/Installation.md