Лучший подход для базы данных длинных строк

12

Мне нужно хранить вопросы и ответы в базе данных. Вопросы будут от одного до двух предложений, но ответы будут длинными, по крайней мере, параграф, вероятно, больше.

Единственный способ сделать это прямо сейчас - это база данных SQL. Однако я не думаю, что это хорошее решение, потому что, насколько я видел, эти базы данных не используются для данных такого типа или размера. Это правильный путь или есть лучший способ сохранить эти данные? Есть ли лучший способ хранения необработанных строк?

database database-design

— gsingh2011
источник

Вы смотрели в полнотекстовый поиск? ru.wikipedia.org/wiki/Full_text_search

— FrustratedWithFormsDesigner,

Пожалуйста, определите "длинный" 1 КБ, 5 МБ, 1 ГБ ??

— Джеймс Андерсон

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

— PSR

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

— gsingh2011

1

Какую СУБД вы используете? Oracle имеет отличную поддержку для обработки и поиска текста.

— Мэтью Флинн

19

Mongodb великолепен, но вы знаете SQL. Нет ничего плохого в хранении длинных ответов в полях. Вы можете хранить изображения или даже файлы в SQL. Я думаю, что максимальный размер поля составляет 2 ГБ.

Я почти уверен, что этот ответ хранится где-то в поле таблицы.

Что касается их тысячи, нет проблем. Даже миллионы не должны быть проблемой. Вы можете рассмотреть возможность использования полнотекстовой индексации, если вы ищете в поле ключевые слова или что-то еще. Но я стараюсь не оптимизировать, пока не увижу проблему. Компьютеры дешевы, хранение в основном бесплатное.

— DanielEli
источник

11

+1 на неоптимизацию, пока у вас не возникнет проблема!

— GrandmasterB

4

Максимальный размер поля не указывается в ANSI SQL, он зависит от СУБД (и обычно нескольких других факторов, таких как кодировка, тип данных столбца, механизм хранения, ОС и т. Д.).

— tdammers

6

Нет проблем с хранением длинного текста в базах данных (SQL или иначе). Вот как хранится практически каждая запись в блоге (например, Wordpress), новостная статья и пост на форуме (например, phpbb) в Интернете. Я не знаю конкретных деталей настройки обмена стека, но я уверен, что ваш вопрос также хранится в базе данных. Большинство баз данных SQL имеют TEXTтип поля или эквивалентный только для хранения текстовых данных любой длины. Многие также имеют полнотекстовые поисковые системы.

Принимайте технические решения, основываясь на технических знаниях и понимании, а не на чувствах.

— GrandmasterB
источник

5

Да, это правильный путь. Хранение строк в базе данных SQL - это то, что вы хотите сделать. В одной из моих таблиц в БД есть данные в виде открытого текста, и она работает нормально.

Если вы беспокоитесь о месте для хранения - помните, что это дешево!

Если вы беспокоитесь о производительности - тогда не беспокойтесь, хорошая база данных может масштабироваться (или уменьшаться) до того количества данных, которое вы хотите добавить в нее.

Последнее, что вы хотите сделать, это начать оптимизировать сейчас ради этого (сжатие строк перед тем, как поместить их в БД или что-то в этом роде), прежде чем это действительно станет проблемой. Вы просто даете себе больше работы.

— Rocklan
источник

2

Нет проблем с хранением больших строк или двоичных данных. Я работал с базой данных, содержащей более одного терабайта двоичных данных, и работал очень хорошо (postgres), и единственной плохой вещью было время резервного копирования.

Большой вопрос: «Вам нужно будет постоянно искать в этом тексте?»

Если вы собираетесь искать строки в тексте, вы можете подумать об одном решении по индексам:

В базе данных есть некоторые данные, которые зависят от поставщика, например Postgres Полный текст: http://www.postgresql.org/docs/9.4/static/textsearch.html
На стороне приложения есть много хороших вариантов, таких как Lucene (Java): http://lucene.apache.org/core/

— Родриго Менезес
источник