MySQL автоматически увеличивает размер ячейки?

Question

[My1Name]

Если в ячейку типа TEXT не влазят данные, MySQL автоматически увеличит её до необходимого размера или выдаст исключение? Как сделать "резиновую" ячейку в таблице?

Answer 1

[Akina]

Если в ячейку

В MySQL нет "ячеек" - это не Excel. Есть записи, есть поля, есть поле отдельной записи.

Если в ячейку типа TEXT не влазят данные, MySQL автоматически увеличит её до необходимого размера или выдаст исключение?

Если размер данных превышает размер для типа данных поля - будет выдана ошибка или предупреждение "data too long". Что именно будет выдано - зависит от того, какой запрос, и от текущих настроек сессии.

Как сделать "резиновую" ячейку в таблице?

Никак. Но если нужно помещать в таблицу данные, которые не лезут в LONGTEXT (а это ни много ни мало 4 гигабайта!) - то Вы явно выбрали инструмент не по задаче. Храните такое в файловой системе.

Comments

[My1Name]

Никак

- плохо...

если нужно помещать в таблицу данные, которые не лезут в LONGTEXT

На старте поле (ячейка) может быть пустым, а с течением времени заполняться. И чтоб не ходить вокруг да около, вкратце речь идёт о поле "заблокированные". Пользователь сайта может заблокировать одного пользователя, и тогда даже типа TEXT - много... А может психануть и блокировать всех подряд в течение месяца. И что тогда делать? :) Мало того, что возникает необходимость проверять каждый раз размер этого поля, накладывается другой вопрос: Он (или его) больше не сможет блокировать?

Вы явно выбрали инструмент не по задаче. Храните такое в файловой системе.

Хранить такие данные в файловой системе?

[Алексей Уколов]

Ну так не нужно хранить обычный реляционный список в виде текста и проблемы не будет никакой.
Храните блокировки в отдельной таблице или в крайнем случае в колонке с типом JSON.

[Akina]

My1Name,

речь идёт о поле "заблокированные". Пользователь сайта может заблокировать одного пользователя, и тогда даже типа TEXT - много... А может психануть и блокировать всех подряд в течение месяца. И что тогда делать?

Переделывать систему. Предварительно прочитав про проектирование баз данных ну хоть что-нибудь.

[My1Name]

Алексей Уколов,

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

Можно по подробней? - Я пишу список ID в виде стрингов. Как можно такие данные хранить в ещё более оптимальной форме?

[Rsa97]

My1Name, Просто создаёте отдельную таблицу blocked_users (user_id, blocked_user_id).

[My1Name]

Rsa97,

Просто создаёте отдельную таблицу blocked_users (user_id, blocked_user_id).

с полем LONGTEXT в 4 гигабайта? :)

[Rsa97]

My1Name, Зачем? С отдельной строкой на каждую блокировку.

[Daemon23RUS]

My1Name,
https://habr.com/ru/articles/193136/ - читать, потом думать, затем делать.

[My1Name]

Rsa97,

С отдельной строкой на каждую блокировку.

Как это понять? Вот например Akina написал/а:

В MySQL нет "ячеек" - это не Excel. Есть записи, есть поля, есть поле отдельной записи.

Что такое "отдельная строка" в вашем понимании?

[Rsa97]

My1Name, Строка - запись.
Для каждой отдельной блокировки создаётся отдельная запись, в которой только id заблокировавшего и id заблокированного. При снятии блокировки эта запись удаляется.

[My1Name]

Rsa97,

Просто создаёте отдельную таблицу blocked_users (user_id, blocked_user_id).

Для каждой отдельной блокировки создаётся отдельная запись

Вы имеете ввиду, создавать отдельную таблицу для каждого пользователя?! Правильно? Чем тогда такой метод отличается от хранения данных в файловой системе? - С новой строки можно писать тупо в файл. А проверить, существует ли ID в файле - "секундное" дело. Самое затратное (по времени) в таком случае - перезапись файла.

[Rsa97]

My1Name, Нет. Таблица одна.

[Василий Банников]

My1Name,

На старте поле (ячейка) может быть пустым, а с течением времени заполняться. И чтоб не ходить вокруг да около, вкратце речь идёт о поле "заблокированные". Пользователь сайта может заблокировать одного пользователя, и тогда даже типа TEXT - много... А может психануть и блокировать всех подряд в течение месяца. И что тогда делать? :) Мало того, что возникает необходимость проверять каждый раз размер этого поля, накладывается другой вопрос: Он (или его) больше не сможет блокировать?

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

Пусть будет таблица, назовём её Blocklist - всего две колонки:
Кто заблокировал, кого заблокировал.

Когда пользователь кого-то блокирует - просто вставлять в неё новую запись.

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

[Василий Банников]

My1Name, зачем на каждого пользователя таблицу создавать?
У нас же специально в таблице есть колонка чтобы различать, кто кого блокирует.

[My1Name]

Василий Банников,

зачем на каждого пользователя таблицу создавать?

А как вы себе это представляете?

Просто создаёте отдельную таблицу blocked_users (user_id, blocked_user_id)

Допустим, есть таблица "Users". В ней хранятся основные данные всех пользователей. Чтоб писать список "blocked" с новой строки, относящийся к конкретному пользователю, таблица "blocked_users" у каждого пользователя должна быть своя.

[Алексей Уколов]

А как вы себе это представляете?

My1Name, вам уже показали структуру таблицы (одной на всех), объяснили типы колонок в ней. Прочитайте внимательно ещё раз комментарии выше. Если всё равно непонятно, то ссылку на учебник вам тоже выше дали.

Допустим, есть таблица "Users". В ней хранятся основные данные всех пользователей. Чтоб писать список "blocked" с новой строки, таблица "blocked_users" у каждого пользователя должна быть своя.

Не должна.

[Василий Банников]

My1Name,

Чтоб писать список "blocked" с новой строки, относящийся к конкретному пользователю, таблица "blocked_users" у каждого пользователя должна быть своя.

1. Не надо мыслить списками. Надо мыслить таблицами
2. Зачем каждому своя таблица?
Если нужно будет получить список пользователей, которых заблокировал пользователь 'A', то просто делаем запрос:

select blocked_user_id from blocked_users where user_id = 'A'

Одна таблица на всех получается.

Ты бы ещё на каждого пользователя новую таблицу создавал, а имя и прочие атрибуты - на разных строках э той таблицы))

[My1Name]

Rsa97, спасибо за ответ. Я вас понял... Я почему-то "упёрся" в PRIMARY KEY и поля с одинаковыми ID не вписывались в представление.

[My1Name]

Василий Банников,

Если нужно будет получить список пользователей, которых заблокировал пользователь 'A', то просто делаем запрос

Какова скорость такой выборки, скажем при 100млн. записей в таблице? MySQL группирует данные с одинаковыми id, если при создании таблицы добавить INDEX по одному из полей?

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

[Василий Банников]

My1Name, какой индекс повесишь, так и будет.
Можно вообще partitioning включить по этому полю - тогда выборка будет всё равно что select * from без where.

[Василий Банников]

My1Name, а тут PK композитный должен быть и строиться не сочетании user_id + blocked_id

[Akina]

Василий Банников,

и строиться на сочетании user_id + blocked_id

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

[Василий Банников]

Akina, зависит от того какие запросы будут.
В первую очередь я о том, что уникальной является сама пара значений

[My1Name]

Василий Банников,

какой индекс повесишь, так и будет.

Я немного удивлён такому решению... Недавно строил график средствами java с TXT файлов ISC: Event catalogue... Всего 140 шт. (на локальном диске ~471 МБ). На старом ноутбуке ASUS с процессором Intel 2Core N3350 up to 2.4GHz под win10, время на чтение+парсинг, вычисления и построение графика: ~19 sec. То есть, один такой файл читается менее 1 секунды. И у меня сложилось какое-то спорное мнение, по поводу эффективности реляционных БД при построении списка "заблокированные", относящегося к конкретному пользователю...

График:
140 файлов

[Василий Банников]

My1Name, не совсем понял

И у меня сложилось какое-то спорное мнение, по поводу эффективности реляционных БД при построении списка "заблокированные", относящегося к конкретному пользователю...

Почему?

[My1Name]

Василий Банников, потому что NoSql мне кажется будет быстрее и эффективнее.

[Василий Банников]

My1Name, почему?

[My1Name]

Василий Банников, NoSql архитектура - это прямой доступ к файлам, которые гораздо меньше конечной (проектируемой) таблицы.

[Василий Банников]

My1Name,

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

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

А в случае, если у тебя индекс есть, то на вопрос "заблокировал ли пользователь А пользователя Б" ты получишь ответ за почти константное время.

[My1Name]

Василий Банников,

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

В основной таблице (БД) хранятся ссылки...

кто такое сказал?

Отвечаю - я! :)

в случае, если у тебя индекс есть, то на вопрос "заблокировал ли пользователь А пользователя Б" ты получишь ответ за почти константное время.

Так на самом деле гораздо проще. Легче добавить вспомогательную таблицу, чем писать дополнительные инструменты.