[БД] Что делать, если хочется всё хранить в БД?

БДГМ.

По сути - БД включают SQL, но не ограничиваются им. Так штааа...

Ну да! Добавить сюда ещё и NoSQL -> это будет эпичнейший прирыв в области иифнормационных технологий.

Обострение?

Было на Microsoft Developers Conference 20 лет назад.

>Что делать, если хочется всё хранить в БД?

Какие-то, может быть, успокоительные принять? Если совсем плохо, с психологом можно посоветоваться.

У вас просто плохая ФС (с)

Нет, мне тоже хотелось бы все хранить в БД. И выбирать предметы так: «SELECT item FROM clothing WHERE type=„socks“ AND last_worn < last_washed;», но я понимаю, что это пока невозможно.

Попробуй залить туда фильм и оцени удобство использования, особенно скорость чтения

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

> Что делать, если хочется всё хранить в БД?

Хранить всё в БД.

Я ожидал такой ответ :)

Видеофайлы будут разбиваться на блоки по ключевым кадрам. При чтении - запрос на нужный блок + несколько блоков наперед для кэширования (сейчас то же происходит на ФС, разве не так?).

Какое именно?

Плюсую этого оратора.

> несколько блоков наперед для кэширования

Круто, да. На последующем поиске сэкономишь, а данные всё равно будешь гонять по IPC.

Файловая система это тоже БД.

> ЛОР, что со мной не так?

Синдром утенка.

Лечится просто. SQL-инъекция в мозг и всё путём.

Что делать, если хочется всё хранить в БД?

Принять галоперидолу. Если желание ограничивается только хранением в БД бизнес-логики, то можно обойтись и менее ядрёными веществами, и лечением амбулаторно

Спасибо, первый вменяемый коммент по теме. Это многое проясняет.

ФС и есть грубо говоря key-value storage, с иерархически упорядоченными ключами.

>ЛОР, что со мной не так?

Захотелось написать самому WinFS?

> ЛОР, что со мной не так?

Тебя укусил Балмер и ты хочешь WinFS.

>>ЛОР, что со мной не так?

Узость кругозора, очевидно же. 40-летняя фрезеровщица тоже мыслит философскими категориями Привода, Болванки и Фрезы. Только у неё нет возможности светить тупизной на виду у всех.

> Я даже начинаю задумываться, а почему не хранить в БД всё? Абсолютно всё.

ЛОР, что со мной не так?

С тобой всё нормально. Это как юношеские прыщи - проходит само со временем.

> Я даже начинаю задумываться, а почему не хранить в БД всё? Абсолютно всё.

Слишком много служебных данных => низкий КПД.

Как остынет максимализм, станет понятно что «всё» заменится на «многое», что, в свою очередь, заменится на «кое что».

А вчера в ванной, мне преснился чудный сон, как будто я нырнул в море, и оно прератилось в SQL, рыбы, водоросли, медузы, все из SQL, даже небо, даже Аллах!.

> И выбирать предметы так: «SELECT item FROM clothing WHERE type=„socks“ AND last_worn < last_washed;», но я понимаю, что это пока невозможно.

Я хочу такой интерфейс (или подобный) к своему комоду.

> Я даже начинаю задумываться, а почему не хранить в БД всё? Абсолютно всё.

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

Еще вспомнилась копипаста: «...а я люблю обмазываться реляционными базами данных. Выхожу в интернет каждый день с большим винчестером, и кладу в него все базы данных, которые только могу найти...»

>а почему не хранить в БД всё? Абсолютно всё.

Как вариант - загони БД в саму БД.

http://www.linux.org.ru/news/opensource/2913026 --- аццкий баян

>Как остынет максимализм, станет понятно что «всё» заменится на «многое», что, в свою очередь, заменится на «кое что».
Ксати, почему в линуксе нет поддержки общесистемной БД для «кое-чего», расположенной на отдельном разделе (либо LVM, с автоуправлением размером LV), интеграцией юниксовых прав и стандартизованным API для доступа?

Да нафига тебе этот костыль в виде БД. Лучше уже сразу АИ изобрести, где ты будешь давать запросы и пожелания на естественном языке.

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

Интеграция юниксовских прав, это я как понимаю отдельные права для каждой записи?

ЛОР, что со мной не так?

Ты изобрел WinFS!

>Интеграция юниксовских прав, это я как понимаю отдельные права для каждой записи?
Ну да, хотя бы в некоторых таблицах. Первостепенно не это, а стандартизованный API.

>Ну да, хотя бы в некоторых таблицах.
Например, чтобы распилить /etc/passwd и /etc/shadow (собственно, тут хорошо вписывается реляционная БД), дать каждому пользователю редактировать свою запись (естественно, не все поля) и избавиться от suid на passwd.

Стандарт SQL в качестве API подойдет?

В следующем комментарии мне нужно будет открыть для себя O_DIRECT и ненужность голых разделов для БД?

Зачем для этого реляционность?

>Стандарт SQL в качестве API подойдет?
Какая часть libc его умеет, кстати?

Та же часть, которая обеспечивает доступ к реляционной бд.

>Зачем для этого реляционность?
Пользователям не стоит редактировать свой UID (он в отдельной таблице), но вполне можно редактировать остальное. Таблицы слинкованы по UID.
Пример надуманный, но в реальной жизни подобное было бы полезно.

Может это остальное класть в ~/.user просто?

>Может это остальное класть в ~/.user просто?
Можно. Но иногда несколько конфигов явно реляционно связаны (/etc/passwd и /etc/shadow).
Ещё бы не помешала общесистемная nosql БД на кэш (с возможностью выкинуть кэш при нехватке свободного места).
Файлы — это прекрасно, но в некоторых случаях интересно работать с данными, а не файлами.

А именно, в тех случаях когда данные являются метаданными.

В принципе можно конечно, но из-за одной связи по ID, без индексов, сортировок, триггеров и прочего мы получаем раздувание ядра ПО плюс обязательное шифрование файла таблицы, отсутствие возможности редактирования без специальных инструментов, невозможность использования индекса для таблиц у которых права пользователей зависят от ячейки и ведерко потенциальных багов.
Насчет общесистемной nosql БД на кэш, абсолютно не понимаю зачем это пихать в ядро системы, если memcache легко ставится и везде работает.
Да и не юникс-вейно как-то.

>отсутствие возможности редактирования без специальных инструментов
Э? Если данные в БД — полноценный объект в ОС, то для работы с ними точно есть удобные инструменты. Да и динамические файлы в linux давно уже существуют, пусть и только в отдельных ФС (компенсируется симлинками).

Насчет общесистемной nosql БД на кэш, абсолютно не понимаю зачем это пихать в ядро системы, если memcache легко ставится и везде работает.

Не memcache. Нечто для данных, которые хранятся на диске, и которые при необходимости (нехватка места) можно выкинуть. Прозрачно для прикладного софта (поэтому и часть системы).
Затачивать под конкретное решение — неЪ, лучше прослойка для возможного расширения.
~/.cache — шаг в том направлении, но его иногда используют как /var, поэ
тому чистить небезопасно.

не юникс-вейно как-то.

Есть юниксвейный метод работы с блобами? Дублирующиеся данные — юниксвей?
И насквозь постюникс-вейная p9 из коробки умеет динамические файлы, которые могут делать в том числе и подобные сервисы.

В общем, я хочу, чтобы в ОС данные были на равных правах с файлами. Со всеми вытекающими последствиями.