- 1
- 2
$user_id = $engine->auth->id;
$sql = "SELECT `id` FROM `arm_tasks` WHERE (followers_id = '{$user_id}' OR followers_id LIKE '{$user_id},%' OR followers_id LIKE '%,{$user_id},%' OR followers_id LIKE '%,{$user_id}') ";
Нашли или выдавили из себя код, который нельзя назвать нормальным, на который без улыбки не взглянешь? Не торопитесь его удалять или рефакторить, — запостите его на говнокод.ру, посмеёмся вместе!
+156
$user_id = $engine->auth->id;
$sql = "SELECT `id` FROM `arm_tasks` WHERE (followers_id = '{$user_id}' OR followers_id LIKE '{$user_id},%' OR followers_id LIKE '%,{$user_id},%' OR followers_id LIKE '%,{$user_id}') ";
Вот так отжигает товарищ по отделу.
Поле followers_id в виде строки с id-шниками через запятую (что тоже не очень хорошо)
сказали же, "не очень хорошо"
т.е. оно как бы и ничего, но всё же что-то тут не так...
нет
показалось
Как вариант - были всегда (гуглить лень), просто последние несколько лет я провёл в анабиозе, и привык к огнептице. Зачем тогда ломать "стандарты" и выдумывать? Непонятно.
Дык и character varying и varchar, емнип, из стандарта SQL. И оба варианта работают в слонике. Что не так то?
> ломать "стандарты"
Лолшто, SQL 92 с тобой не согласен:
SQL defines distinct data types named by the following <key word>s: CHARACTER, CHARACTER VARYING, BIT, BIT VARYING, NUMERIC, DECIMAL, INTEGER, SMALLINT, FLOAT, REAL, DOUBLE PRECISION, DATE, TIME, TIMESTAMP, and INTERVAL.
1) CHAR is equivalent to CHARACTER. DEC is equivalent to DECIMAL. INT is equivalent to INTEGER. VARCHAR is equivalent to CHARACTER VARYING. NCHAR is equivalent to NATIONAL CHARACTER.
Это ораклопроблемы.
Наверное, раньше было как-то больше варчаров, а сейчас - не очень.
Остальные пишут varchar и не парятся :)
Только консолька, только хардкор ;)
P.S. А вот pgdump говорит, что таки character varying. Не уверен, от чего это зависит.
Разницы то никакой, просто показывает первый попавшийся алиас для этого типа.
ну там иерархию построить: наследование, полиморфизм
и хранить их всех в одной единой таблице, в колонке с базовым типом
а то ведь оракл считает, что бд вполне себе место для таких акробатик
вынуждают, суки
В колонку слоник позволяет упихать массивы, структуры, hstore (аля key-value хранилище в колонке) и json.
А наследование там только на уровне таблиц - select из родительской возвращает заодно строчки из унаследованных от нее.
> в колонке с базовым типом
Ну прям в колонку нельзя, но ведь джойн с полиморфной табличкой никто не отменял.
http://sqlfiddle.com/#!15/58f8f/1
только hibernate
только assparallel
конечно
это всё кривая скользкая дорожка, заманивает переносить нетривиальную логику с сервера прямо в бд
объекты в оракле уже в двух весьма нагруженных задачах заюзал, полет нормальный
через 100 лет это всё перепишут жавоёбы, потребив нехило серверной памяти и своих трудочасов, но это будет уже совсем другая история
Ностальжи...