Как хранить много строк длинных строк в mySQL

Question

Мне нужно сохранить 100 URL-адресов + 100 текстовых меток. Я хотел бы иметь значение по умолчанию для обоих. Проблема, с которой я столкнулся, заключается в том, что я установил поля URL как VARCHAR, length = 1024 и текстовые метки как VARCHAR, длина = 30. При построении моей таблицы я столкнулся с ошибкой: «Размер строки слишком большой. максимальный размер строки для используемого типа таблицы, не считая BLOB, составляет 65535. Вам нужно изменить некоторые столбцы на TEXT или BLOB «

Как еще я могу выполнить свою задачу? Я не могу использовать TEXT b/c, он не позволяет мне сохранить значение по умолчанию для этого поля.

Answer 1

Имея 100 полей в записи для этого, прямо, неправильно. Не делай этого.

Вместо этого создайте новую таблицу с ее собственным основным и внешним ключом, привязанным к родительской таблице, и каждая из строк в этой таблице может содержать URL и метку. Затем вы можете заставить приложение обеспечить, чтобы в этой таблице хранилось не более 100 строк на родителя.

Да, идиома сильно отличается от того, что у вас есть сейчас, но это намного, намного лучше.

Edit для комментариев:

SQL лучшие модели "коллекции вещей" в качестве строк в таблицах. Классическая точка обсуждения в модели базы данных - это когда вы говорите об определенной части данных. Вопрос неизбежно сводится к тому, что «будет один из этих предметов или много».

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

Прямо сейчас вы можете иметь что-то вроде:

create table user { 
    id number primary key not null, 
    firstName varchar(30), 
    lastName varchar(30), 
    url1 varchar(1024), 
    url1label varchar(30), 
    url2 varchar(1024), 
    url2label varchar(30), 
    url3 varchar(1024), 
    url3label varchar(30), 
    url4 varchar(1024), 
    url4label varchar(30) 
} 

Имея повторяющиеся поля, как это «плохо» шаблон в базах данных SQL, как правило. Все правила имеют исключение, но, как правило, когда вы только начинаете, это плохая идея. Как минимум, вы занимаете место для всех этих полей url, независимо от того, сколько они фактически используют.

Во-вторых, с точки зрения SQL эти многочисленные, повторяющиеся поля чрезвычайно трудны в работе. Например, вы не можете легко запросить базу данных, чтобы узнать, есть ли у кого-нибудь http://google.com в качестве URL-адреса. Вы должны были бы иметь что-то ужасное, как:

select * from user where url1 = "http://google.com" or url2 = "http://google.com" ... 

Так, а лучшая модель будет что-то вроде:

create table user { 
    id number primary key not null, 
    firstName varchar(30), 
    lastName varchar(30), 
} 

create table urls { 
    id number primary key not null, 
    user_id number not null references user(id), 
    url varchar(1024), 
    label varchar(30) 
} 

Здесь каждый URL строка имеет свой собственный первичный ключ, и ссылка на пользователь, которому принадлежит url через user_id.

Если вы хотите, чтобы получить все URL-адресов для пользователя вы могли бы сделать:

select * from urls where user_id = 123 

Теперь база данных не дает никаких ограничений на сколько ссылок пользователь может держать. Пользователь может иметь 0 или 1 или миллион. В базе данных не будет применяться какой-либо предел. Если вы хотите ограничить их до 100 URL-адресов, ваше приложение должно будет сделать это самостоятельно.

Но, надеюсь, вы увидите, что если один пользователь имеет 2 URL-адреса, они будут иметь только 2 строки в таблице URL-адресов, тогда как у пользователя с 50 URL-адресами будет 50 строк.

Для других полей, в которых у вас есть только 1 (например, имя и фамилия), все они могут быть полями в основной пользовательской таблице.

Но поля, которые повторяются, скорее всего, лучше представлены в их собственную таблицу с внешним ключом к родителю

Answer 2

Is ОКЕЙ, имеющих поля VARCHAR длиной 1024 и другой длины 30. Доказательство: http://sqlfiddle.com/#!2/8d4f7/1024

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

Но, проблема в том, что общая длина вашей таблицы строки не должно быть больше, чем 65532.

Ссылки: http://www.pythian.com/blog/text-vs-varchar/