"Укутываение" текста

[FANTAzeRus]

"Укутываение" текста

Написал запрос, который при выводе списка постов "укутывает" текст длинной более N=символов, в данном случае 500 и закрывает его фразой "Читать дальше", вот собсна сам запрос:
SELECT
ca.cid,
ca.title,
ca.opened,
ca.clevel,
ca.type,
DATE_FORMAT(ca.cdat,'%d.%m.%Y %H:%i:%s') dat,
IF(LENGTH(co.text)>500,CONCAT(SUBSTRING(co.text,1,500),'<br>...<br>Читать дальше<a href=\"post_',co.cid,'.html\"><b>\"',ca.title,'\"</b></a>'),co.text) text,
u.type ust,
u.nik
FROM cat ca
LEFT JOIN users u ON(u.id=ca.user)
LEFT JOIN content co ON(co.cid=ca.cid)
WHERE ca.clevel>2 and ca.cid>1 and ca.wis='Y' and ca.title
ORDER BY ca.dat DESC

Но есть ОГРОМНЫЙ минус такого метода - это абсолютно непредсказуемое обрезание текста, надеюсь понятно! Дык вот, можно это конечно решить следующим образом: уже в коде скрипта отрезать все лишнее с конца до ближайшего пробела, НО есть жгучее желание все это реализовать в запросе ... не подскажете ли в каком направлении крутить???

 

[Demiurg]

ужас какой ... не стоит таких запросов писать.
А какие проблемы со скриптом ?

 

[FANTAzeRus]

А почему это не стоит???
Со скриптом нет НИКАКИХ проблем!

 

[Demiurg]

1. В запросе html - это очень плохой знак. В базе данных должны храниться данные а не их представление.
2. Читать такой запрос не удобно.
3. Если нет проблем со скриптом в чем тогда вопрос ?

 

[FANTAzeRus]

1. В запросе html - это очень плохой знак. В базе данных должны храниться данные а не их представление.

В базе храниться только текст! ТЫ вобщем суть запроса уловил??? HTML добавляется в запросе!!!

2. Читать такой запрос не удобно.
Кому???

3. Если нет проблем со скриптом в чем тогда вопрос ?
Хочу сделать Чтобы Мускулом это обрабатывалось!!! Время выполения Одинаково!

 

[Demiurg]

>В базе храниться только текст! ТЫ вобщем суть запроса уловил??? HTML добавляется в запросе!!!
запросы тоже относятся к базе.

>Кому???
тому, кто после тебя будет читать.

>Хочу сделать Чтобы Мускулом это обрабатывалось!!! Время выполения Одинаково!
зачем ?

 

[FANTAzeRus]

>тому, кто после тебя будет читать.

Меня абсолютно не трогает что кому то трудно будет читать мои запросы, кто отлично ЗАНАЕТ Мускул поймет все сразу

>Зачем?
Затем что все эти функции писались для того, чтобы использоваться!!!!

И Ваще ХВАТИТ воду лить и Флуд разводить я спрашивал конкретные решения оной проблемы средствами Мускула а не Скриапта! Ферштейн?Ни в одном твоем посте я ничего относящегося к вопросу не увидел ... не зря у тебя статус Второй Флудер ...

 

[lucas]

FANTAzeRus

Значит так. Объясняю медленно.

Это.
Не.
Нужно.
Делать.
Средствами.
Базы.
Данных.

Это.
Нужно.
Делать.
В.
Скрипте.

 

[Demiurg]

>Меня абсолютно не трогает что кому то трудно будет читать мои запросы, кто отлично ЗАНАЕТ Мускул поймет все сразу
тогда я не знаю mysql и ничем помочь не могу.

 

[FANTAzeRus]

>тогда я не знаю mysql и ничем помочь не могу

А на кой тогда вобщем Выступать было? Мля ненавижу таких "УМНИКОВ"!

 

[lucas]

FANTAzeRus

Какой-то ты непонятливый. Повторяю:

Это.
Не.
Нужно.
Делать.
Средствами.
Базы.
Данных.

Это.
Нужно.
Делать.
В.
Скрипте

 

[FANTAzeRus]

Автор оригинала: lucas
FANTAzeRus

Значит так. Объясняю медленно.

Это.
Не.
Нужно.
Делать.
Средствами.
Базы.
Данных.

Это.
Нужно.
Делать.
В.
Скрипте.

Честно? Меня не устраивает ТАКОЙ ответ! Ибо толку в нем не больше чем в ответах Демимурга! Если ты профессионал, то объясни мне с профессиональной точки зрения, ПОЧЕМУ стоит делать так, а не иначе!!!

 

[Demiurg]

>А на кой тогда вобщем Выступать было?
Я не выступал, я пытался наставить тебя на путь истиный, но похоже бесполезно. Попробуй хотя бы лукаса послушать.

 

[lucas]

Если ты профессионал, то объясни мне с профессиональной точки зрения

Не надо брать меня на "слабо" или пытаться померяться пиписькой. Этим на досуге ты можешь заняться с кем-нибудь другим.
______________________________________

Фактически, ты пытаешь получить из БД данные, на которые уже наложено представление.

Ты реализуешь в запросе логику представления:
1. Условные действия (IF);
2. HTML-код с форматированием;
3. Гиперссылки...
...тогда как Деми уже несколько раз тебе сказал, что в БД или в запросах к ней не должно быть и намека на логику представления.

Такой путь грозит тебе -- самое меньшее -- большими проблемами со сменой представления (дизайна), из-за полной невозможности сопровождения скрипта.

Ты должен понимать, что скрипт должен быть поделен на логические блоки: конфигурация -> обработка запроса пользователя -> получение данных -> создание представления -> вывод.

Ты же пытаешься совместить несколько этапов, чем создаешь 0% удобства -- одни проблемы.
Например, мне не дадут соврать, что CONCAT и иже с ними -- довольно ресурсоемкие операции, так что список потенциальных проблем дополняется тормозами в БД -- тебе это надо?

Мой совет: не маяться дурью, а делать "по уму", то есть так, как написал Деми и я.

P. S.: Повторять это я не буду.

 

[.des.]

Ты реализуешь в запросе логику представления:
1. Условные действия (IF);

условные действия IF в запросе - это инструмент который избавляет от ОЧЕНЬ многих лишних телодвижений.

Не вижу ничего плохого, что наряду с самой немодифицированной ссылкой, возвращается и ее представление (до 500 символов).

Если потом эту фразу действительно придется отрезать в скрипте до ближайшей точки не превышая 500 символов и сделать это скрипте - то не вижу никакого повышения читабельности.

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

Например, мне не дадут соврать, что CONCAT и иже с ними -- довольно ресурсоемкие операции, так что список потенциальных проблем дополняется тормозами в БД -- тебе это надо?

Да это действительно так например уже при выборке 1000 записей наличие CONCAT в запросе явно сказывается на производительности, но фраза имеет смысл если CONCAT в запросе будет применяться к большему числу строк, чем в скрипте. В другом случае очень сложно представить что mysql concat будет медленнее.

 

[lucas]

[::без желания спорить/разводить флейм::]

Не вижу ничего плохого, что наряду с самой немодифицированной ссылкой, возвращается и ее представление (до 500 символов).

И тут настала смена дизайна...

И еще, прошу прокомментировать следующее:

Скрипт должен быть поделен на логические блоки[, которые не нужно совмещать друг с другом]: конфигурация -> обработка запроса пользователя -> получение данных -> создание представления -> вывод.

 

[Demiurg]

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

 

[.des.]

Скрипт должен быть поделен на логические блоки[, которые не нужно совмещать друг с другом]: конфигурация -> обработка запроса пользователя -> получение данных -> создание представления -> вывод

С этим утверждением я не спорю, поэтому оно и не прокоментированно.

И тут настала смена дизайна....

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

2Demiurg
Вы с lucas ему с самого начала ответили. Я отметил лишь несколько моментов. Фантазеру сложно помочь, он априори уверен, что делает все верно.

 

[csa]

>Каким образом смена дизайна и количество обрезаемых символов связано?
например, захотели изменить количество символов. или вообще отказались

 

[sokol]

FANTAzeRus
Просто пример:
Тебе захотелось изменить атрибут class у ссылки. Придется искать этот запрос и исправлять там. Где же тут удобство сопровождения?

Может быть так поймешь.