Работа функции???

Kostya\spb

Новичок
Работа функции???

Есть вывод из базы новости потом идет
$news = mysql_fetch_array($query);

Дальше допустим так идет:

echo "[".added($news[added])."] $news[news]";

То он выдает ошибку:
Notice: Use of undefined constant added - assumed 'added' in C:\server\www\news.php on line 15

если написать так added($news['added']) то все нормально, ошибко нету.

Вопрос: Почему здесь надо писать ковычки а в $news[news] ненадо. Или где функция added там может как то по другому написать надо?

П.С. в функции added зделан обычный preg_replace
типа из (timestamp) 20050718151743 заменяет на 18.07.2005 и все.
 

kvf77

Red Devil
Kostyaspb

учи матчасть - название полей в ассоциированном массиве надо брать в кавычки - одинарные или двойные. в противном случае, PHP ищет константу с таким именем - не находит ее и выдает тебе ошибку
 

Kostya\spb

Новичок
Ну почему в $news[news] кавычек ненадо. а там надо. вроде бы из одной темы берутся данные.
 

kvf77

Red Devil
Kostyaspb

тебе сказали как надо - ты будешь спорить?
и там надо и там и запомни - ВСЕГДА надо

к тому же, у тебя $news подургому записана, нежели предыдущая команда, ее тоже правильнее записать также как функцию added
 

SelenIT

IT-лунатик :)
Ну почему в $news[news] кавычек ненадо.
http://www.php.net/manual/ru/language.types.string.php. Как правильно говорит kvf77, надежнее и универсальнее выносить все массивы из строк и везде использовать кавычки для строковых индексов.

...preg_replace ... из (timestamp) 20050718151743 заменяет на 18.07.2005...
Не нужно. http://dev.mysql.com/doc/mysql/ru/date-and-time-functions.html (конкретно - DATE_FORMAT) прямо в запросе.
 

kvf77

Red Devil
Kostyaspb
скажем - так правильнее и надежнее

еще совет - если в кавычках ты не помещаешь символов типа \n\r и других подобных, а также переменных (например, "ddd $news"), то бери эти данные в одинарные (') кавычки
 

rtrim()

Guest
Автор оригинала: kvf77
Kostyaspb
скажем - так правильнее и надежнее

еще совет - если в кавычках ты не помещаешь символов типа \n\r и других подобных, а также переменных (например, "ddd $news"), то бери эти данные в одинарные (') кавычки
Правильный совет. Увеличивается (совсем ненамного) производительность, т.к. скрипт не парсит такую строку на наличие спец. символов, переменных,..
 

Kostya\spb

Новичок
kvf77 так? echo '['.added($news['added']).']'.$news['news'];

SelenIT
Получается так надо сделать? (сначало изменить формат даты в базе).
SELECT DATE_FORMAT('2005-07-18 15:17:43', '%d.%m.%Y');
 

kvf77

Red Devil
Kostyaspb

угу - само то.
что касается формата даты - то зачем сначала? делай все в одном запросе
 

SelenIT

IT-лунатик :)
Не надо ничего в базе менять
А запрос примерно такой:
SELECT DATE_FORMAT(added, '%d.%m.%Y') AS added1, ..., FROM ...

и при выводе из базы работать с полем $news['added1']
 

Kostya\spb

Новичок
kvf77 SelenIT
Не ну как бы вообще чтобы данные в другом виде хранились. Вместо TIMESTAMP поставить тип DATETIME.

Мне впринцыпе дата нужна только в виде DD.MM.YYYY
Но если в базе написать так то сортировка неполучается.
 

kvf77

Red Devil
Kostyaspb
чушь - как не получается? ORDER BY должен рабоать с реальной датой
 

SelenIT

IT-лунатик :)
Kostyaspb
судя по моему опыту, DATE_FORMAT прекрасно работает с TIMESTAMP. Основнрое различие между TIMESTAMP и DATETIME далеко не в формате представления даты. TIMESTAMP нужен в тех ситуациях, для которых создан - чтобы автоматически запоминать время создания либо любого (!) изменения записи.
 

rtrim()

Guest
Автор оригинала: Kostya\spb
kvf77 SelenIT
Не ну как бы вообще чтобы данные в другом виде хранились. Вместо TIMESTAMP поставить тип DATETIME.

Мне впринцыпе дата нужна только в виде DD.MM.YYYY
Но если в базе написать так то сортировка неполучается.
Универсально - это хранить timestamp от 1 января 1970: time()
и преобразовывать в любые даты командой date()
 

SelenIT

IT-лунатик :)
rtrim()

Это неуниверсально. Так не получится хранить, например, даты рождения людей старше 35 лет. Инструменты нужно использовать по назначению. У MySQL очень мощные средства работы с датой, главное - уметь их применять.
 

kvf77

Red Devil
rtrim()

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

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

rtrim()

Guest
Автор оригинала: SelenIT
rtrim()

Это неуниверсально. Так не получится хранить, например, даты рождения людей старше 35 лет. Инструменты нужно использовать по назначению. У MySQL очень мощные средства работы с датой, главное - уметь их применять.
это правда - неудачную я характеристику подобрал...
 

SelenIT

IT-лунатик :)
Kostyaspb
Лично я ничего не имею против TIMESTAMP, если уверен, что дата не "вылезет" за пределы 1970-2038гг. Если важно записывать именно дату добавления чего-то в базу, ИМХО TIMESTAMP весьма удобен. Так что на твоем месте я бы ничего в базе не менял.
 
Сверху