Посоветуйте базу данных.

[Kit]

Всем добрый вечер.

 

Есть задумка хранения ряда текстовых данных. К примеру, есть лингвистический текст, со знаками препинания. Делю текст на предолжения, или даже на более мелкие фрагменты, например слова. Получившийся фрагмент может быть длинной более 255 символов, а может и не быть :)

Хочу использовать базу MySQL или PostgreSQL.

Какой тип поля выбрать для хранения данных фрагментов, чтобы место на жестком диске диске, где располагается база, использовалось наиболее рационально? Чтобы не оставалось значительного зарезервированного места по длине данных. Данные в поле изменяться не будут, один раз пишутся, без абдейта.

Буду признателен за рекомендации базы данных, типа поля и настроек. Заранее спасибо.

[n00ne]

не совсем понятна задача. точнее совсем не понятна. зачем текст хранить в БД? и что Вы с ним хотите там делать?

[Neinsager]

Ага. Так как совершенно непонятно зачем это всё нужно, то ответ будет буквальный...

 

таблица из трёх полей (типы приведены для MySQL):

quotation_id (тип mediumint unsigned) — уникальный номер предложения;

part_id (тип smallint unsigned) — номер части предложения;

quotation_part (тип char(20) ) — часть предложения.

 

При внесении данных исходное предложение разбивается на куски по 20 символов. При выборке — склеивается, с отсечением возможных лишних пробелов в конце последнего фрагмента.

Таким образом — на каждом предложении мы впустую используем максимум 19 байт :)

[n00ne]

Schwein, ну тут как бы вообще нафига? ну и разбитие тоже нафига?))))))))))))

[Neinsager]

n00ne

Чтоб жизнь мёдом не казалась :) Пошутил я.

 

А если серьёзно — blob'а должно хватить за глаза, только за индексацию, если она нужна, подумать дополнительно.

[Andreios]

char(20) - а чего именно 20? :)

ps

все тот же "деготь" в "медовой жизни"? ))

[Kit]

не совсем понятна задача. точнее совсем не понятна. зачем текст хранить в БД? и что Вы с ним хотите там делать?

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

 

to Schwein - не хочу бить по 20 символов. Видимо, буду бить по точкам и переводу каретки. Бить нужно, чтобы минимизировать повторяемость фрагментов. В принципе, самый "крутой" способ - разбить на слова пробелами.

 

Про индексацию - тут вообще головная боль, но это уже второй этап :)

 

Как бы так.

[Neinsager]

Kit

Ну так blob, насколько я помню, занимает при хранении данных n+2 байт на запись, где n — кол-во символов в записи. Т.е. с точки зрения хранения потерь почти нет.

[Kit]

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

[Gennadyi]

http://ru.wikipedia.org/wiki/MUMPS

[alexk]

PostgreSQL, обычный тип данных TEXT.

 

При размере текста до 128 байт - заголовок аттрибута данного типа занимает 1 байт

При размере больше 128 байт - заголовок занимает 4 байта, но может включаться компрессия (LZ), которая достаточно эффективна для текстовых данных.

 

Ну и обычный overhead любой СУБД - 24 байта на заголовок каждой страницы (8Кб) + 4 байта указатель на каждую строку + 24 байта заголовок каждой строки.

 

Размер индекса предсказать сложно, но в среднем где-то 1/10 - 1/5 от размеров таблицы при использовании btree индекса (есть еще GIN и GIST, которые могут лучше подходить для текстовых данных, особенно в случае полнотекстового поиска).

 

Размер исходных данных еще зависит от их кодировки, латинские буквы в большинстве кодировок представляются одним байтом, а вот кириллица как правило в UNICODE кодировках, таких как UTF-8, занимает 2 байта, поэтому если стоит задача максимально экономного хранения русского текста - я бы взял однобайтовую кодировку, скажем KOI8-R (нужно указать initdb при инициализации базы).

 

Возможно не стоит средствами СУБД делать систему контроля версий, а посмотреть на уже работающие SVN, GIT + WebDAV для доступа (или, если хранить репозиторий на сервере, обычный CGI скрипт, запускающий клиента напрямую)?

 

Помимо реляционных есть еще документно-ориентированные СУБД (MongoDB, CouchDB): http://en.wikipedia.org/wiki/Document-oriented_database, возможно они лучше подойдут для данной задачи, если отдельные данные, хранящиеся в таблице, не связаны или слабо связаны между собой.

[Kit]

Спасибо за ответы. Многое прояснилось.

 

Использовать сторонние сервисы SVN не хотелось бы, поскольку возлагаемая на ресурс задача (хранение информационных статей) вполне решаема его ресурсами. Скорее всего на роль хранилища данных возьму постгрес.