newsTable
id, name, title, text, brief, picture, meta, hurl, enabled
pageTable
id, name, title, text, brief, picture, date, meta, hurl, enabled
Дата записи MySql
Существует ли запрос MySQL который позволяет получить дату и время внесения записи в базу?
чтото вроде "GETTIME FROM table Where id=10" ?
чтото вроде "GETTIME FROM table Where id=10" ?
Цитата: SibBear
Существует ли запрос MySQL который позволяет получить дату и время внесения записи в базу?
чтото вроде "GETTIME FROM table Where id=10" ?
чтото вроде "GETTIME FROM table Where id=10" ?
ответа на ваш вопрос незнаю =), но не проше ли создать дополнительную ячейку напимер: `date` и при операциях с базой её обновлять =)
Цитата: shureg
ответа на ваш вопрос незнаю =), но не проше ли создать дополнительную ячейку напимер: `date` и при операциях с базой её обновлять =)
ну так то проще, но в этой таблице есть строки, у которых даты может не быть, а пустые ячейки выбивают таблицу из 3й НФ,
соответственно, либо делать доп. таблицу с данными, либо получать дату путем операций над таблицей...
Что ж это за нормальная форма, у которой есть строки, у которых дат быть не может?
Это уже разнотипность данных в рамках одной таблицы, что имхо, быдлокодство.
По крайней мере делайте новое поле, а для тех, кто не имеют их, ставьте значение по-умолчанию, например 1970-00-00 00:00:00
Это уже разнотипность данных в рамках одной таблицы, что имхо, быдлокодство.
По крайней мере делайте новое поле, а для тех, кто не имеют их, ставьте значение по-умолчанию, например 1970-00-00 00:00:00
Все просто, есть новости, и статьи, полностью идентичные данные кроме даты
Я хочу не делать две одинаковых таблицы, а сделать просто ключ, новость это или статья.
Дату буду делать как Вы предложили, спасибо!
Я хочу не делать две одинаковых таблицы, а сделать просто ключ, новость это или статья.
Дату буду делать как Вы предложили, спасибо!
Лучше все таки разнести данные по разным таблицам.
Цитата: UAS
Лучше все таки разнести данные по разным таблицам.
+1
НФ-ы не всегда хорошо.
Часто для того чтобы возможно было что-то реализовать приходится уходить от НФов.
Я бы вобще сделал 3 таблицы.
1 - с общими данными
две другие имеют данные свойственны каждой из сущосностей. и связал их по ПК.
Это сразу дает возможность без каких либо потерь и головной боли расширить сущонсть в будущем. Например, нужно будет ввести автора статьи, или еще что-то
С общими это лишнии джоины))) По мне лучше 2 таблицы разные. Вообще, когда я писал CMSку (как давно это было), которую потом неоднократно использовал, то у всех таблиц были 3 служебных поля (кстати это очень удобно, хоть и добавляет избыточность) это __id, __createDate, __modifyDate.
Цитата: shaelf
С общими это лишнии джоины))) По мне лучше 2 таблицы разные. Вообще, когда я писал CMSку (как давно это было), которую потом неоднократно использовал, то у всех таблиц были 3 служебных поля (кстати это очень удобно, хоть и добавляет избыточность) это __id, __createDate, __modifyDate.
Да join-ы лишнии есть, но зато если надо реализоывать систему комментов, или еще чего-то где свзка 1-ко-многим, то наоборот уменьшает кол-во таблиц или полей.
а про поля created_at и modificated_at, эт да - удобно. Я щас на symfony+doctrine пишу проэкт, так тут вобще в схеме задется деректива и ОРМ сама генерит эти поля и сама их заполняет
Наиболее оптимальным вариантом будет действительно создание просто еще одного поля с датой.
Я не очень умею работать с форматом "1970-00-00 00:00:00", а вот с unix timestamp (который возвращается функцией time()) - вродь ничего...
Таким образом, у вас получится таблица типа:
__________________________________________
| id | subject | body | addtime |
------------------------------------------------
| 2 | Заголовок | текст | 12239429329 |
__________________________________________
А потом этот timestamp можно будет переделывать как угодно при выводе.
$date = date('d.m.Y', $mysql["addtime"]);
$date2 = date('H:i:s d/m/Y', $mysql["addtime"]);
И т.п., т.е. выводить в том формате, в котором вам удобно...
Минус - не наглядная запись в БД... С другой стороны - 1234567890 - это 10 байт против 19... экономия места в базе в 2 раза )))
Я не очень умею работать с форматом "1970-00-00 00:00:00", а вот с unix timestamp (который возвращается функцией time()) - вродь ничего...
Таким образом, у вас получится таблица типа:
__________________________________________
| id | subject | body | addtime |
------------------------------------------------
| 2 | Заголовок | текст | 12239429329 |
__________________________________________
А потом этот timestamp можно будет переделывать как угодно при выводе.
$date = date('d.m.Y', $mysql["addtime"]);
$date2 = date('H:i:s d/m/Y', $mysql["addtime"]);
И т.п., т.е. выводить в том формате, в котором вам удобно...
Минус - не наглядная запись в БД... С другой стороны - 1234567890 - это 10 байт против 19... экономия места в базе в 2 раза )))
P.S. перед записью в базе не забудьте получить время.
$time=time();
mysql_query("insert into news_table (id, subject, body, addtime) values (NULL, '$subj', '$body','$time'");
$time=time();
mysql_query("insert into news_table (id, subject, body, addtime) values (NULL, '$subj', '$body','$time'");
Для чего? NOW(), UNIX_TIMESTAMP() уже отменили? К тому же у временных полей можно параметром поставить, чтобы по умолчанию вставлялось текущее время (если ничего не вставляешь)
2Lone Wolf Без этого тоже замечательно делается)) Можешь создать топик - обсудим или в личку.
2Kesano UNIX_TIMESTAMP спасёт тебя (за подробностями в маны)... Так же есть FROM_UNIXTIME()
2Lone Wolf Без этого тоже замечательно делается)) Можешь создать топик - обсудим или в личку.
2Kesano UNIX_TIMESTAMP спасёт тебя (за подробностями в маны)... Так же есть FROM_UNIXTIME()
Цитата: shaelf
Для чего? NOW(), UNIX_TIMESTAMP() уже отменили? К тому же у временных полей можно параметром поставить, чтобы по умолчанию вставлялось текущее время (если ничего не вставляешь)
2Lone Wolf Без этого тоже замечательно делается)) Можешь создать топик - обсудим или в личку.
2Kesano UNIX_TIMESTAMP спасёт тебя (за подробностями в маны)... Так же есть FROM_UNIXTIME()
2Lone Wolf Без этого тоже замечательно делается)) Можешь создать топик - обсудим или в личку.
2Kesano UNIX_TIMESTAMP спасёт тебя (за подробностями в маны)... Так же есть FROM_UNIXTIME()
Создал. http://forum.codenet.ru/showthread.php?t=62913
2Kesano а ПХПшечке есть strtotime().
Цитата: shaelf
2Kesano UNIX_TIMESTAMP спасёт тебя (за подробностями в маны)... Так же есть FROM_UNIXTIME()
Только зачем для этого дела напрягать Мускуль???..
А если дату нужно изменить???
А если время MySQL-сервера отличается от времени Веб-сервера???
Писать для этого в мускуле ИМХО бред...
Придерживайтесь принципа KISS... С помощью мускуля многое можно... вопрос: зачем? тем более что вопрос задал человек, который не очень с ним дружит...
Цитата: Lone Wolf
2Kesano а ПХПшечке есть strtotime().
Ага...
Преобразовывает 1970-00-00 00:00:00 в timestamp для того, чтобы потом с помощью date вывести его в нужном формате...
Еще один бред... ЗАЧЕМ??? лишних "движений" нехватает???
Ну вот, начлось... Как в старые добрые времена... :)))
Значится так...
>> А если время MySQL-сервера отличается от времени Веб-сервера???
Ты такое хоть раз видел (меньше 1 сек не рассматривается)? Лично я - нет. Опыта хватает :)
>>Придерживайтесь принципа KISS...
Его-то я и придерживаюсь :)
>> А если дату нужно изменить???
Что значит "дату нужно изменить"? Речь шла о времени записи.
Значится так...
>> А если время MySQL-сервера отличается от времени Веб-сервера???
Ты такое хоть раз видел (меньше 1 сек не рассматривается)? Лично я - нет. Опыта хватает :)
>>Придерживайтесь принципа KISS...
Его-то я и придерживаюсь :)
>> А если дату нужно изменить???
Что значит "дату нужно изменить"? Речь шла о времени записи.
Ну я встерчал разное время на мускуль сервере и вэб.
Вэб сревак в киеве, мускуль в Варшаве, но если ты об этом знаешь, кто тебе мешает ввести ссответсвующую поправку?
Далее, зачем мне напрягатся и при любом инсерте в таблицу, создании контента, автоматическом событии.. вытягивать время и сохранять его, если за меня все это сделает мускуль да еще и без моего ведома.. Чем я его так напрягу? Одной функцией получения времени? Неужели он от этого загнется?
Ну а если дату изменить надо, то впреде менй. что тебе мешает?
Вэб сревак в киеве, мускуль в Варшаве, но если ты об этом знаешь, кто тебе мешает ввести ссответсвующую поправку?
Далее, зачем мне напрягатся и при любом инсерте в таблицу, создании контента, автоматическом событии.. вытягивать время и сохранять его, если за меня все это сделает мускуль да еще и без моего ведома.. Чем я его так напрягу? Одной функцией получения времени? Неужели он от этого загнется?
Ну а если дату изменить надо, то впреде менй. что тебе мешает?
>>Вэб сревак в киеве, мускуль в Варшаве
Мне одному кажется это бредом?:)) Или может я просто последние года 4 работал с относительно нагруженными проектами (пару лет в точке отсчёта провёл) и забыл как по другому может быть?:)
Теперь по поводу KISS. В переводе на русский это значит "делай проще". Вот только мне одному кажется, что
"INSERT INTO table (title) VALUES ('title string')"
пишется и читается проще чем
$time = time(); //А если у нас дата, а не timestamp, то мы ещё должны сформировать число из этого
"INSERT INTO table (`date`, title) VALUES($time, 'title string')"
Посмотри на эти 2 записи и скажи, какая больше нравится.
Мне одному кажется это бредом?:)) Или может я просто последние года 4 работал с относительно нагруженными проектами (пару лет в точке отсчёта провёл) и забыл как по другому может быть?:)
Теперь по поводу KISS. В переводе на русский это значит "делай проще". Вот только мне одному кажется, что
"INSERT INTO table (title) VALUES ('title string')"
пишется и читается проще чем
$time = time(); //А если у нас дата, а не timestamp, то мы ещё должны сформировать число из этого
"INSERT INTO table (`date`, title) VALUES($time, 'title string')"
Посмотри на эти 2 записи и скажи, какая больше нравится.
Цитата: shaelf
>>Вэб сревак в киеве, мускуль в Варшаве
Мне одному кажется это бредом?:))
Мне одному кажется это бредом?:))
Нет, не тебе одному :)
Просто такая ип%%%тая политика "безопасности" была в конторе где я работал.(Дочерная фирма одной польской копорации)
Ммм... безопасности... Гнать по http трафик уже безопасно ?)))) Или вы там через ssl гоняли?)) Бррр... Не, в таких не работал :)
Та не. политика все сервера - должны быть у них..
Но в силу специфичности проэкта, получилось выбить установку вэбсерваков в Украине.. но остальное не отдали..
Ладно это оффтоп
Но в силу специфичности проэкта, получилось выбить установку вэбсерваков в Украине.. но остальное не отдали..
Ладно это оффтоп
Цитата: Lone Wolf
+1
Я бы вобще сделал 3 таблицы.
1 - с общими данными
две другие имеют данные свойственны каждой из сущосностей. и связал их по ПК.
Это сразу дает возможность без каких либо потерь и головной боли расширить сущонсть в будущем. Например, нужно будет ввести автора статьи, или еще что-то
Я бы вобще сделал 3 таблицы.
1 - с общими данными
две другие имеют данные свойственны каждой из сущосностей. и связал их по ПК.
Это сразу дает возможность без каких либо потерь и головной боли расширить сущонсть в будущем. Например, нужно будет ввести автора статьи, или еще что-то
Идея правльная, возможно потом чтото и понадобится, только я не все понимаю...
вот конкретная таблицы, которая есть
id int(11)
parent_type int(11) новость, статья, просто описание чегото и т.п (всего там около 15 типов)
parent_id int(11) соответственно ключ по которому цепляем
text text сам текст
brief text краткое описание
date дата (которую собственно выносим)
Как из этого правильно сделать гибкую таблицу?
Да, и ксати правильно подмечено, дружу я с мускулем по мере надобности, уж очень я меркантильный :) как записать, вынуть, сцепить и т.п. знаю, а вот как грамотно таблицу составить, эт как то сложно, тем более что таблиц из 5 при моей попытке привести в норму уже стало 25 (ну а что делать, там было по 20 полупустых полей в каждой...)
Откуда вообще полупустые поля?. Принципы посторения (не задумываясь вообще простые). Если таблица ПОСТОЯННО связывается 1 ко многим (допустим комменты), то добавляем parentId, если она цепляется ещё к разным таблицам, то tableName. Если цеплять нужно иногда, то заводи отдельную таблицу для связывания. Нужны новости? Не нужно расширять какую-то таблицу, делай новую. Если фанат ООП структуры, то используй постгресс (он поддерживает наследование таблиц). Всё :)
SibBear зайди в соседнюю тему, там shaelf вобще красивый способ предложил.
А мой основывался на том что в таблице новстей ПК ключ, аткже является сслыкой на ИДшник из общей таблицы.
Т.е для выборки всей информации по новстям, ты делаешь селект из таблицы новстой и join по ИД общую таблицу...
А мой основывался на том что в таблице новстей ПК ключ, аткже является сслыкой на ИДшник из общей таблицы.
Т.е для выборки всей информации по новстям, ты делаешь селект из таблицы новстой и join по ИД общую таблицу...
Цитата: shaelf
Если фанат ООП структуры, то используй постгресс (он поддерживает наследование таблиц). Всё
Это вот Вы сейчас с кем разговаривали? :)
Я просто переделываю то, что мне досталось, перерабатываю сайт. После перехода на join увеличил производительность почти в двое (да, там были использованы циклические запросы, ну не я же их придумал..), но структура таблиц меня просто убивает... Начал проектировать и в ступоре...
И потом правильно тут сказали, у меня постоянно возникает необходимость добавить какой нибудь параметр, и из за него переписывать все запросы я не осилю, поэтому надо продумать таблицы...
Ну можешь скинуть текущюю структуру (дамп без данных) и небольшое ТЗ (что нуно) и мы вместе попробуем построить структуру. Заодно ты на этом примере (живом, с которым ты работаешь) поймёшь что к чему, да и другим будет польза.
PS postgreSQL это БД :)
PS postgreSQL это БД :)
А вот и есть собственно маленькое тз, это по большому счету самая сложная таблица, на которой я уперся...
было
и еще около 5-7 подобных таблиц
что я сделал
1. вытащил все поля meta, hurl, title и прочую сео шелуху в таблицу
id,
parent_type (от чего именно это свойство)
parent_id (собственно номер владельца)
type (что это, meta, title или еще что)
text (собственно само значение поля)
что это дало: если какое то поле не использовалось, было пустым или еще что, то теперь я просто запись не делаю в таблицу, размер меньше - уже хорошо
2. вытащил поле text и brief в отдельную
теперь похоже, надо и их разбивать, т.к. краткого описания может не быть, опят напоримся на пустое поле...
3. вытаскиваем дату в отдельную таблицу.
В итоге мне кажется, что все стало в два раза сложнее, за счет полей parent_type и parent_id
Что я выигрываю за счет обхединения news и pages в одну таблицу разбивая ключем type? А похоже что ничего, кроме того, что у меня не 7 таблиц как раньше, а 1 с типом, но к ней еще прицеплено так же 5 маленьких таблицек, которые из за необходимости определения типа родителя опять вырастают...
допустим у статьи всегда есть текст, но может не быть краткого описания, какогото мета поля, автора или еще чего. Поэтому текст можно оставить и в основной таблице... У новости тоже самое...
Так может оставить отдельно news и pages но вынести из них необязательные поля в отдельную таблицу?
да, и пока работаем через join, что такое Линковочные таблицы это следующий этап развития :)
сейчас у меня
T_Info
T_Seo
что я могу собрать из этих таблиц:
. -тип страницы - любой
данные:
. - уникальный номер,
. - название
. - текст
. - краткое описание
. - любое количество различных сео данных
что плохо:
. - снова при добавлении того же автора, слету ничего не получится
было
Код:
и еще около 5-7 подобных таблиц
что я сделал
1. вытащил все поля meta, hurl, title и прочую сео шелуху в таблицу
id,
parent_type (от чего именно это свойство)
parent_id (собственно номер владельца)
type (что это, meta, title или еще что)
text (собственно само значение поля)
что это дало: если какое то поле не использовалось, было пустым или еще что, то теперь я просто запись не делаю в таблицу, размер меньше - уже хорошо
2. вытащил поле text и brief в отдельную
теперь похоже, надо и их разбивать, т.к. краткого описания может не быть, опят напоримся на пустое поле...
3. вытаскиваем дату в отдельную таблицу.
В итоге мне кажется, что все стало в два раза сложнее, за счет полей parent_type и parent_id
Что я выигрываю за счет обхединения news и pages в одну таблицу разбивая ключем type? А похоже что ничего, кроме того, что у меня не 7 таблиц как раньше, а 1 с типом, но к ней еще прицеплено так же 5 маленьких таблицек, которые из за необходимости определения типа родителя опять вырастают...
допустим у статьи всегда есть текст, но может не быть краткого описания, какогото мета поля, автора или еще чего. Поэтому текст можно оставить и в основной таблице... У новости тоже самое...
Так может оставить отдельно news и pages но вынести из них необязательные поля в отдельную таблицу?
да, и пока работаем через join, что такое Линковочные таблицы это следующий этап развития :)
сейчас у меня
T_Info
Код:
id int(11)
parent_id int(11)
parent_type int(11)
description text
brief text
date timestamp
parent_id int(11)
parent_type int(11)
description text
brief text
date timestamp
T_Seo
Код:
id int(11)
parent_id int(11)
parent_type int(11)
seo_type varchar(255)
seo_value varchar(255)
parent_id int(11)
parent_type int(11)
seo_type varchar(255)
seo_value varchar(255)
что я могу собрать из этих таблиц:
. -тип страницы - любой
данные:
. - уникальный номер,
. - название
. - текст
. - краткое описание
. - любое количество различных сео данных
что плохо:
. - снова при добавлении того же автора, слету ничего не получится
Цитата: SibBear
Что я выигрываю за счет обхединения news и pages в одну таблицу разбивая ключем type?
Тут уже надо думать логически, в терминах задачи (модели).
Если новость - разновидность страницы с датой, можно объединять. Более того, даже поле дополнительное не нужно, если id суррогатный и сквозной. Можно создать представления:
Код:
create table data_entities(
id, name, title, text, brief, picture, date, meta, hurl, enabled
); /* синтаксис условный */
create view pages as
select
id, name, title, text, brief, picture, meta, hurl, enabled
from
data_entities
where
date is null;
create view news as
select
id, name, title, text, brief, picture, date, meta, hurl, enabled
from
data_entities
where
date is not null;
id, name, title, text, brief, picture, date, meta, hurl, enabled
); /* синтаксис условный */
create view pages as
select
id, name, title, text, brief, picture, meta, hurl, enabled
from
data_entities
where
date is null;
create view news as
select
id, name, title, text, brief, picture, date, meta, hurl, enabled
from
data_entities
where
date is not null;
Похожим образом в PunBB PE объединены сообщения форума и записи блогов с комментариями.
подитог:
мы посовещались и я решил
поскольку в планах реализация модульной системы, оставлена только таблица с заведомо однотипными данными
далее идут модули, которые имеют свою собственную таблицу
новости
статьи
ну и т.п.
таблиц получается много (все маленькие), но при ненадобности можно просто удалить определенный модуль вместе с таблицами...
и думаю дальше нет смысла усложнять...
мы посовещались и я решил
поскольку в планах реализация модульной системы, оставлена только таблица с заведомо однотипными данными
Код:
id int(11)
parent_type int(11)
parent_id int(11)
text text
brief text
parent_type int(11)
parent_id int(11)
text text
brief text
далее идут модули, которые имеют свою собственную таблицу
новости
Код:
id int(11)
name varchar(255)
date timestamp
name varchar(255)
date timestamp
статьи
Код:
id int(11)
name varchar(255)
автор varchar(255)
name varchar(255)
автор varchar(255)
ну и т.п.
таблиц получается много (все маленькие), но при ненадобности можно просто удалить определенный модуль вместе с таблицами...
и думаю дальше нет смысла усложнять...
Ща наверное с фрименом подерёмся :)). Может мой подход не всех устраивает, но по мне он удобен и логичен (многие поклонники НФ меня ногами запинают :) ). В общем по мне новость, это новость. Т.е. в ней есть id, data, lid, text и т.д. и наружу можно выносить только вещи для повторного использования (например автор или ссылка на источник, если она (новость) берётся). Всё остальное это излишества. Как вариант можно выносить у новости сам текст (новость) для оптимизации скорости (тогда списки новостей быстрее работать будут, но это актуально только для крупных сайтов).
Теперь что касается view. Штука забавная, интересная... Но по мне она немного унылая и нужна только для специфических вещей. Она просто создаёт некий удобный интерфейс, но не более. При запросе на view делается (мускулом) запрос сначала на неё, потом выполняется запрос который представляет сама вьюха. В общем скоростью тут не пахнет :)
Теперь что касается view. Штука забавная, интересная... Но по мне она немного унылая и нужна только для специфических вещей. Она просто создаёт некий удобный интерфейс, но не более. При запросе на view делается (мускулом) запрос сначала на неё, потом выполняется запрос который представляет сама вьюха. В общем скоростью тут не пахнет :)
выносить тайтл, текст и другие вещи удобно для поиска по всему контенту, вывода списка всего контетна... не нужно дергать другие таблицы. Запрос идет только к одной общей....
Модеры, может обьедените две темы? а то как-то об одном и том же в двух темах говорим
Модеры, может обьедените две темы? а то как-то об одном и том же в двух темах говорим
Вот для таких вещей существует сфинкс :))
Цитата: shaelf
Вот для таких вещей существует сфинкс :))
Ну так правильно. сфинкс верент тебе набор ИДшок. Дл отображения списка, достаточно дергнуть общую таблицу..
а также если поиск только по названию и тексту, создается только один индекс..
а в случае множества таблиц возникают доп сложности..
Мне кажется не вариант. Для таких вещей я вьюху делал. Просто в одну таблицу запихивать новости, статьи и т.д. только потому, что так искать удобно мне кажется не айс... Далеко не айс. (был опыт работы с новостными сайтами (weeckend.ru, menu.ru inout.ru и т.д.).
а чем не устроит общаяя таблица для всех объектов системы? чем таки не айс? Танцуем от печки - т.е. любой запрос строится от нее - и в тоже врямя каждый объект может(должен) быть реализован отдельно в таблице?
shaelf та не.. не в одну. общии данные в одну, собственные в другие- то что я в самом начале предлагал
А про искать удобнее, я конечно со сфинксом сталкиваюсь только впервые, и может не все знаю, но мне кажется там не просто удобнее.
Например есть две таблицы Новости, Статьи
Ид, тайтл, текст.... и дальше свои поля.
Допустим имеем, Новость "Копорация Microsoft обанкротилась" с id - 5, и статью "Как повесить Microsoft Windows" с id -3 .
Описываем два сорса и два индекса, пускаем поиск по запросу Microsoft по двум индексам. Сфинкс вернет 3,5 как различить что к чему?
А про искать удобнее, я конечно со сфинксом сталкиваюсь только впервые, и может не все знаю, но мне кажется там не просто удобнее.
Например есть две таблицы Новости, Статьи
Ид, тайтл, текст.... и дальше свои поля.
Допустим имеем, Новость "Копорация Microsoft обанкротилась" с id - 5, и статью "Как повесить Microsoft Windows" с id -3 .
Описываем два сорса и два индекса, пускаем поиск по запросу Microsoft по двум индексам. Сфинкс вернет 3,5 как различить что к чему?
2kot_ Проходили уже, при относительно больших данных забрать что-то из мускула становится ооооочень сложно
2Lone Wolf sphinx давно научился прикидываться мускулом и может возвращать тебе что угодно. Опять же зависит всё от реализации.
2Lone Wolf sphinx давно научился прикидываться мускулом и может возвращать тебе что угодно. Опять же зависит всё от реализации.
Слйшайте, а к слову о поиске, смотрите ведь как удобно
все тексты с описаниями в одной таблице, пробег по ней и вывел
найдено:
новостей 10 => ссылка
статей 15 => ссылка
описаний 48 => ссылка
еще чего то там 21 => ссылка
выбрал что нужно, и читай себе наздоровье :)
или не?
все тексты с описаниями в одной таблице, пробег по ней и вывел
найдено:
новостей 10 => ссылка
статей 15 => ссылка
описаний 48 => ссылка
еще чего то там 21 => ссылка
выбрал что нужно, и читай себе наздоровье :)
или не?
Ага, а так же постоянный +1 к where при простой выборке.