Закодировать в одном integer два значения

Предположим, есть только одно Int поле, в котором надо хранить колво лайков и дизлайков. Простой и расточительный подход: первые 2 цифры - это колво лайков, 2 младшие - это кол-во дизлайков.
Пример:
0100 - это есть 01 00, т.е. один лайк, 0 дизлайков
9921 - это есть 99 21, т.е. 99 лайков, 21 дизлайк

Подбный подход не сортируется в MySQL SORT по данному полю в логике формулы
лайки - дизлайки = значение для сортировки.
Т.е. хранить можно, но сортировать логически корректно не получится. Можно ли придумать подход, который и хранить кол-во лайков\дизлайков и при этом сортировка срабатывала бы корректно?

А если лайков/дизлайков будет больше 100?

Можно взять изначально большего порядка число слепок, пусть будет число с 6-ю нулями для 999 лайков и дизлайков! ХЗ, если привысится и этот лимит, то пусть будет сброс до разницы, т.е. 999100 в момент переполнения сбрасывается до 899000, а 100999 до 000899.
Опять же я привёл изначально плохой пример. Может стоит поиграться с другими системами счисления до заворачивания результата в Int, что будет менее расточительно и решит задачу с сортировкой.

похоже на удаление зуба через жопу

А почему бы не взять и не сделать 2 инта для таких операций? Учитывая, что лайков много быть не может. Вполне хватит smallint в бд, у которого 2 байта. Делаем его unsigned типа и вот тебе почти 65к лайков. Не думаю что стока когда-либо налайкают. Итак. У нас есть лаки с 2 байтам. Теперь делаем тоже самое с дизлайками. Это тоже 2 байта. Итого 4. Это ровно столько же, сколько и просто int. Без ебических заморочек. + можно сортировать

SAV писал:

похоже на удаление зуба через жопу

тестовое задание походу какоето.
в реале такой бред никто не использует.

S_Flash писал:

Предположим, есть только одно Int поле, в котором надо хранить колво лайков и дизлайков. Простой и расточительный подход: первые 2 цифры - это колво лайков, 2 младшие - это кол-во дизлайков. Пример: 0100 - это есть 01 00, т.е. один лайк, 0 дизлайков 9921 - это есть 99 21, т.е. 99 лайков, 21 дизлайк Подбный подход не сортируется в MySQL SORT по данному полю в логике формулы лайки - дизлайки = значение для сортировки. Т.е. хранить можно, но сортировать логически корректно не получится. Можно ли придумать подход, который и хранить кол-во лайков\дизлайков и при этом сортировка срабатывала бы корректно?

нахуя? даже если паковать два числа в одну колонку - вычисляемое поле будет без индекса - а это расчет и нагрузка при каждом запросе.

а так то поле сортировки предварительно вычислять тоже лучше по какото формуле. и не просто вычитанием.

Ailk писал:

А почему бы не взять и не сделать 2 инта для таких операций?

Как отсортировать по популярности в SQL стиле, в смысле, по лайк - дизлайк?

SAV писал:

похоже на удаление зуба через жопу

В информатике и системном программировании, где есть элементы связывающие машину с внешним миром очень много таких "зубов". Взять хотябы, как машина работает с десятичными дробями.
Если идти в лоб логики лайков и дизлайков, то задача решается хоть и легко, но очень избыточно, надо хранить 3 поля\столбца в базе (лайк, дизлайк, разница (индекс для сортировки)) и менять одновременно минимум 2. Это возможно но не всегда оптимально.

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

S_Flash писал:

Как отсортировать по популярности в SQL стиле, в смысле, по лайк - дизлайк?

например вот так =)
http://stackoverflow.com/questions/34111209/mysql-order-by-like-dislikes-and-popularity

Задание бредовое, но если очень надо - делаем примерно так:
int = (like-dislike)*10000 + (like*100) + dislike
получаем фактически 3 части - разница (первые 2 знака), лайки (средние 2 знака), дислайки (последние 2 знака), и при этом можем без проблем сортировать "по популярности" штатными средствами.
Да и по любым другим критериям в принципе тоже - например SORT BY SUBSTRING(var,-2) легко сделает сортировку только по дислайкам

sonata писал:

Задание бредовое, но если очень надо - делаем примерно так: int = (like-dislike)*10000 + (like*100) + dislike получаем фактически 3 части - разница (первые 2 знака), лайки (средние 2 знака), дислайки (последние 2 знака), и при этом можем без проблем сортировать "по популярности" штатными средствами. Да и по любым другим критериям в принципе тоже - например SORT BY SUBSTRING(var,-2) легко сделает сортировку только по дислайкам

По моему все проще можно сделать:
Пример:
0100 - это есть 01 00, т.е. один лайк, 0 дизлайков
9921 - это есть 99 21, т.е. 99 лайков, 21 дизлайк

1) по лайкам
SELECT .. ORDER BY `X`-`X`%100 DESC

2) по дизлайкам используем остаток от деления
SELECT .. ORDER BY `X`%100 DESC

DF™ писал:

По моему все проще можно сделать: Пример: 0100 - это есть 01 00, т.е. один лайк, 0 дизлайков 9921 - это есть 99 21, т.е. 99 лайков, 21 дизлайк 1) по лайкам SELECT .. ORDER BY `X`-`X`%100 DESC 2) по дизлайкам используем остаток от деления SELECT .. ORDER BY `X`%100 DESC

может оно и проще, но по ресурсам вычислять на каждую запись остаток от деления - сильно затратнее чем часть строки вырезать

sonata писал:

может оно и проще, но по ресурсам вычислять на каждую запись остаток от деления - сильно затратнее чем часть строки вырезать

Не верю! И не забывай что у тебя число изначально, тебе надо его еще перевести в строку прежде чем работать со строками!

Я думал сделать примерно так:
Хранить разницу как первые две старшие цифры (для сортировки ORDER BY без преобразований), две следующих цифры кол-во лайков, две последних - дизлайков:

122614 - это есть 12 - разница лайки - дизлайки, 26 - лайки, 14 - дизлайки
002427 - это есть 00 - беззнаковая разница, 24 - лайки, 27 - дизлайки

Еще на биты можно разложить по 7, с ними еще проще работать (8+7+7 бит)
На разницу 8 бит и хранить как "128 минус разница", тогда по отрицательной разнице сортировать можно будет.