MySQL - Как хранить входные данные неизвестного и различного размера?

Question

Все,

Я пытаюсь создать таблицу для приема пользовательских данных (UGC).Этот контент может варьироваться по размеру от одного символа до нескольких сотен слов.Входные данные будут закодированы в utf8_unicode_ci и могут быть латинскими или многобайтовыми символами.

Входные данные должны быть доступны для поиска.

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

На данный момент я представляю только 2 поля для этой таблицы: идентификатор (автоинкремент INT(10)) и сам UGC,(Мне может понадобиться еще несколько полей, таких как dateAdded и т. Д.)

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

1. Установить верхний предел для размера строки и принять показатели производительности и удобства использования.
2. Создать несколько таблиц для различных диапазонов размеров (и в конечном итоге типов) и идентифицируйте каждый элемент по комбинации имени таблицы и идентификатора (поэтому мне нужна центральная таблица с уникальным идентификатором, именем таблицы, идентификатором таблицы).
3. Я мог бы хранить каждый объект отдельно и простоиметь БД хранить URL.Я подозреваю, что это менее эффективная версия # 2, но я не в себе.

Спасибо,

JDelage

Answer 1

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

Answer 2

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

• Если БД «понимает» содержаниепотенциально BLOBy поле, сохраните его в БД
• Если БД не имеет представления о содержимом, сохраните его внешне

Учитывая это и мой опыт до сих пор, я не рекомендуюиспользование поля BLOB для изображений и т. д.

Теперь, когда мы думаем о контенте, который может быть текстом, изображением или чем-то еще, я вполне уверен, что вашей бизнес-логике понадобится какое-то поле, которое говорит ему, как использовать контентВ любом случае, трудно представить себе приложение, которое будет рассматривать изображение как изображение, просто взглянув на данные.Поэтому я рекомендую вам создать такое поле, на ум придет mimetype и, скажем, поле mediumtext.Бизнес-логика вашего приложения может легко вывести, что mimetype='text/plain' будет означать, что данные в текстовом поле являются полезными данными, а mimetype='image/png' будет означать, что данные в текстовом поле - это (относительный) путь к файловому ресурсу.

Это дает вам возможность поиска и индексации содержимого с довольно низкой вероятностью ложных совпадений, если вы создаете пути к файлам таким образом, что это не будет словом на любом языке.MD5(basename).suffix приходит на ум.

Answer 3

Поскольку вы также упомянули о хранении изображений и не-текста, рекомендуется использовать тип BLOB.* 1002.