Задача заведомо нерешаема, но мало ли, может я не знаю чего...
Вот такой дамп
Полная Версия: Головоломка с уникальными полями
| Цитата |
| CREATE TABLE IF NOT EXISTS `test` ( `date` date NOT NULL, `text` varchar(250) NOT NULL, UNIQUE KEY `key` (`date`,`text`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8; -- -- Дамп данных таблицы `test` -- INSERT INTO `test` (`date`, `text`) VALUES ('2014-03-01', 'a'), ('2014-03-01', 'b'), ('2014-03-02', 'c'), ('2014-03-03', 'd'), ('2014-03-04', 'e'); |
Естественно все упрощено до невозможности, только суть. Мне нужно очистить поле `text` за период < '2014-03-03' Ну примерно таким запросом:
Этого сделать нельзя, так как там уникльный индекс. Но очень надо :D
Может кому придет в голову нестандртное решение? Суть проблемы в том, что поле text занимает много места. И хотелось бы эпизодически чистить таблицу. Ну ли сократить. Допустим записать туда не пустоту, а числа подобные автоинкременту.
Решение есть на уровне PHP, но уж очень топорное. Вдруг кто-нибудь гениальное предложит?
_____________
Если вам недостаточно собственных заблуждений, можно расширить их мнениями экспертов.
Нужно уважать мнение оппонета. Ведь заблуждаться - его святое право.
Настаивал, настаиваю и буду настаивать на своем. На кедровых орешках.
UPDATE test SET `text` = '' WHERE `date` < '2014-03-03'
Этого сделать нельзя, так как там уникльный индекс. Но очень надо :D
Может кому придет в голову нестандртное решение? Суть проблемы в том, что поле text занимает много места. И хотелось бы эпизодически чистить таблицу. Ну ли сократить. Допустим записать туда не пустоту, а числа подобные автоинкременту.
Решение есть на уровне PHP, но уж очень топорное. Вдруг кто-нибудь гениальное предложит?
_____________
Если вам недостаточно собственных заблуждений, можно расширить их мнениями экспертов.
Нужно уважать мнение оппонета. Ведь заблуждаться - его святое право.
Настаивал, настаиваю и буду настаивать на своем. На кедровых орешках.
twin
Может апдейтить поле `text` полем `id`, чтоб сократить размер.
Может апдейтить поле `text` полем `id`, чтоб сократить размер.
| Цитата |
Этого сделать нельзя, так как там уникльный индекс. Но очень надо  |
Немного не понял...как смогут существовать такие две строки, индекс будет не валиден.
_____________
Не тот велик, кто не падал, а тот кто падал и поднимался.
Если подразумевается некое подобие архивации старых данных, то лучше завести отдельную табличку с нужной структурой, ИМХО.
Если нет AI-поля, то как вариант:
1) вычислять хэш текста + даты (но помнить, что в теории возможны коллизии).
2) составлять строку из даты (можно убрать дефисы) + текста, обрезанную до длины ключа.
_____________
Профессиональная разработка на заказ
Я на GitHub | второй профиль
Если нет AI-поля, то как вариант:
1) вычислять хэш текста + даты (но помнить, что в теории возможны коллизии).
2) составлять строку из даты (можно убрать дефисы) + текста, обрезанную до длины ключа.
_____________
Профессиональная разработка на заказ
Я на GitHub | второй профиль
Вся беда в том, что нет там id, так уж устроена таблица. И индекс нужен именно таким.
Архивация да, один из варинтов, но мне не нужны эти данные, а их там гигабайты. Нафиг тратить место...
Даты там повторяются, так что обрезть не выйдет. С хэшем - хорошя идея
32 символа тоже многовато, но на безрыбье, как говорится. Мне идея нравится за то, что можно одним запросом. Спасибо, попробую)))
_____________
Если вам недостаточно собственных заблуждений, можно расширить их мнениями экспертов.
Нужно уважать мнение оппонета. Ведь заблуждаться - его святое право.
Настаивал, настаиваю и буду настаивать на своем. На кедровых орешках.
Архивация да, один из варинтов, но мне не нужны эти данные, а их там гигабайты. Нафиг тратить место...
Даты там повторяются, так что обрезть не выйдет. С хэшем - хорошя идея
32 символа тоже многовато, но на безрыбье, как говорится. Мне идея нравится за то, что можно одним запросом. Спасибо, попробую)))
_____________
Если вам недостаточно собственных заблуждений, можно расширить их мнениями экспертов.
Нужно уважать мнение оппонета. Ведь заблуждаться - его святое право.
Настаивал, настаиваю и буду настаивать на своем. На кедровых орешках.
| Цитата |
| Вся беда в том, что нет там id, так уж устроена таблица. И индекс нужен именно таким. Архивация да, один из варинтов, но мне не нужны эти данные, а их там гигабайты. Нафиг тратить место... Даты там повторяются, так что обрезть не выйдет. С хэшем - хорошя идея 32 символа тоже многовато, но на безрыбье, как говорится. Мне идея нравится за то, что можно одним запросом. Спасибо, попробую))) |
Не хочется наставивать, но id PRIMARY можно же в любой момент создать, все само проставится, уникальное поле и гораздо меньше места чем 32 значный кеш
_____________
Не тот велик, кто не падал, а тот кто падал и поднимался.
Ну там все сложнее гораздо. Там есть PRIMARY ключ, но нет автоинкрементного ID. И по структуре его добавить нельзя. Так уж устроено.
_____________
Если вам недостаточно собственных заблуждений, можно расширить их мнениями экспертов.
Нужно уважать мнение оппонета. Ведь заблуждаться - его святое право.
Настаивал, настаиваю и буду настаивать на своем. На кедровых орешках.
_____________
Если вам недостаточно собственных заблуждений, можно расширить их мнениями экспертов.
Нужно уважать мнение оппонета. Ведь заблуждаться - его святое право.
Настаивал, настаиваю и буду настаивать на своем. На кедровых орешках.
Разреши NULL для text и апдейтни к нулу, а не к пустой строке.
_____________
Mysql, Postgresql, Redis, Memcached, Unit Testing, CI, Kohana, Yii, Phalcon, Zend Framework, Joomla, Open Cart, Ymaps, VK Api
UPDATE test SET `text` = NULL WHERE `date` < '2014-03-03'
_____________
Mysql, Postgresql, Redis, Memcached, Unit Testing, CI, Kohana, Yii, Phalcon, Zend Framework, Joomla, Open Cart, Ymaps, VK Api
T1grOK, блин, ты гений!
_____________
Если вам недостаточно собственных заблуждений, можно расширить их мнениями экспертов.
Нужно уважать мнение оппонета. Ведь заблуждаться - его святое право.
Настаивал, настаиваю и буду настаивать на своем. На кедровых орешках.
_____________
Если вам недостаточно собственных заблуждений, можно расширить их мнениями экспертов.
Нужно уважать мнение оппонета. Ведь заблуждаться - его святое право.
Настаивал, настаиваю и буду настаивать на своем. На кедровых орешках.
Разве прокатит такой финт? По идее, alter table выдаст ошибку, что дубликаты есть. Могу ошибаться, конечно
_____________
Профессиональная разработка на заказ
Я на GitHub | второй профиль
_____________
Профессиональная разработка на заказ
Я на GitHub | второй профиль
| Цитата (Invis1ble @ 14.03.2014 - 07:42) |
| Разве прокатит такой финт? По идее, alter table выдаст ошибку, что дубликаты есть. Могу ошибаться, конечно |
Все прокатит )
+
_____________
Не тот велик, кто не падал, а тот кто падал и поднимался.
_____________
Не тот велик, кто не падал, а тот кто падал и поднимался.
Может я ошибаюсь, но из за NULL поиск по такой таблице с уникальным полем будет медленнее.
_____________
Не тот велик, кто не падал, а тот кто падал и поднимался.
_____________
Не тот велик, кто не падал, а тот кто падал и поднимался.
| Цитата (ABC @ 14.03.2014 - 08:03) |
| Может я ошибаюсь, но из за NULL поиск по такой таблице с уникальным полем будет медленнее. |
Почему бы?
| Цитата (glock18 @ 14.03.2014 - 09:51) | ||
Все прокатит ) |
вообще, я ошибся немного - имел в виду не alter table, а update выдаст ошибку. Ну ладно, поверю на слово
twin, отпишись как всё прошло
_____________
Профессиональная разработка на заказ
Я на GitHub | второй профиль
Invis1ble
в мускуле null не равен null, он вообще ни чему не равен.
в мускуле null не равен null, он вообще ни чему не равен.
Здесь расположена полная версия этой страницы.