Отлично. Попробую тебя навести ну путь истины.
Про класс для работы с БД.
1) возможно эту и ускрит работу
2) так лучше ибо код станет выглядеть так.
- Код: Выделить всё
$db->query("SELECT a FROM b WHERE c");
if($db->error_info(EI_PROCEDURE)
{
echo "Ошибка DB<br>" .
"Код ошибка " . $db->error_info(EI_NUMBER) . '<br>' .
"Описание " . $db->error_info(EI_DESCRIPTION) . '<br>'.
"Поплачте в платок, сайт не загрузится, любимую песню не скачаете";
}
$row = $db->fetch_row();
If($row['artist']=="Gd-78")
{
чтонибудьтам
}
Сделай отдельные методы для начала и "кончала" тразнакций.
Вобщем, код будет читаем.
Я для своего сайта сделал такой класс (причём с DAL).
У меня, например, реализована поддержка уровневого режима работы.
Т.е. модуль позволяет работать сразу с несколькими БД.
Причём я абсолютно не знаю таких проблем как $dbLink и прочее.
у каждой db у меня есть свой алиас. Т.е. её псеводимя.
и я просто делаю так
- Код: Выделить всё
$db->set_db('forum_db')
// все запросы теперь пойдут к этой дб.
$db->set_db('main_db')
// а теперь к главной дб.
и я абсолютно не волнуюсь, не забыть, какой у меня там $dbLink. Я никогда не сохранаю результат запроса в отдельную переменную.
Нет, безусловно, если я дедаю несколько запросов, я могу сделать так:
- Код: Выделить всё
$q1res = $db->query("первый запрос");
$q2res = $db->query("вторй запрос");
$q3res = $db->query("третий запрос");
echo $db->num_rows($q1res);
echo $db->num_rows($q2res);
echo $db->num_rows($q3res);
Но если у меня только 1 запрос с которым я работаю, я ничего не сохраняю и ничего не передаю функциям fetch_row, num_row и прочим. Модуль сам понимает, что речь идёт о прошлом запросе и внутри себя делает всё "по уму".
Теперь об уровнях.
Предположим, что у нас есть некоторая функция А, которая работает не с основной БД.
Т.е. код её примерно такой:
- Код: Выделить всё
function A()
{
global $db;
$db->set_db('some_strange_additional_db');
// Какие то операции.
}
так вот. Эта функция выставляет в качестве дефолтной базы, дополнительную базу.
В этом случае я делаю вероятность ошибки. Допутим какой-то скрипт работает с основной базой, делает 1 запрос, потом вызывает функцию А, потом делает ещё 1 вопрос.
Но функция А поменяет дефолтную базу, и второй запрос выполнится уже на неё. А этого быть не должно. Значит каждая функция перед тем как завершиться, должна ещё и проверять - какая БД была "по умолчанию" до вызова этой функции, и восстанавливать её, если в процессе работы функции была установлена какая-то другая дефолтная бд. Так? А может быть нет? Может быть - пусть код вызывающий функцию должен беспокоиться о том, что она, своей работой может поменять дефолтную базу? Или же не стоит? Просто надо учитывать что откуда вызывается и где нужно менять базу?
Но у меня в одном файле сотни... сотни функций выполняющих какие то операции к БД. И сотни мест, откуда каждая из них когда-либо вызывается.
Не могу я в каждую из них вставить код
(в начале) - $lastdbname = $db->get_db();
(в конце) If($lastdbname!=$db->get_db) { $db->set_db($lastdbname); }
слишком много лишнего, бессмысленного, малоэффективного кода.
И я немогу пологаться на удачу и надеяться на что, что всегда
и до вызова функции,
и после неё, код будет работать с одной и той же базой. Я не робот, я человек - и я могу ошибится. И эти ошибки, будут дорого мне стоить - посетители сайта получат двухстраничный список ошибок. Они уйдут - их и сейчас катострофически нехватает.
Значит я должен предотвратить возможность возникновения таких ошибок, ибо всё это bad-coding. Я решил ввести в модуль БД понятия уровней и субуровней.
Так что моя функция А теперь выглядит так:
- Код: Выделить всё
function A()
{
$db->begin_level('some_level');
// Какой то код.
}
Вот.. под понятием "какой то код" может скрываться всё что угодно - я могу внутри этой функции установить любую базу, сгенерировать любую ошибку.
Понимаешь, у меня оно сделано так - если какая то операция выполняется с ошибкой, информацию (об ошибке) можно всегда получить с помощью с помощью $db->error_info().
Если мой код выглядит так
- Код: Выделить всё
<< ошибочный запрос >>
A();
я буду уверпен что информация об ошибке в "<< ошибочный запрос >>" всегда будет доступна, как информация о самой последней ошибке - т.е. всегда получаема через error_info. И даже если в A() произойдёт своя ошибка, И ДАЖЕ с учётом того что A() работает с той же БД что и основной код, я всё равно после вызова A() получу эту информацию, и именно о той ошибке, которая произошла на первой строчке. И я могу быть уверенным что, каким бы экзотическим не был код A(), после её вызова всё будет так, как будто её не вызывали. Т.е. никаких непредвиденные ошибок не будет.
Всё из за "уровней". Код получается кратким, но не нужно его недооценивать. Нет. Он мощный и гибкий. Не надо думать что из-за этого нововведения я не смогу получить доступ к error-info произошедшей внутри A(). Всё просто - нужно просто указать что я хочу полуить информацию об ошибке, произошедшерй именно на уровне 'some_level'.
Работа на этом уровне может быть даже продолжена из других функций. 2 функции могут работать на одном уровне - с одной и той же БД, пусть даже отличной от той, с которой работает основной код. И что бы не делал основной код между вывовами A и B, в функции B этого не будет заметно. Пусть даже основной код закроет соединение с базой, с которой шла работа на уровне 'some_level'. В функции B всё равно будет возможность продолжения работы с этой базой. Т.е. её по прежнему можно будет set_db(). И эта возможность будет пока уровень не будет complete_level().
Но, опять же, не надо думать что мой код не даёт возможности закрыть соединение с базой так, чтобы она перестала маппиться на всех уровнях - нет, всё это запросто, просто нужно воспользоваться специальной функцией.
Это в чём то похоже на системные прерывания - я могу быть уверен, что после прерывания в регистрах процессора останется то же самое, что и до него. Мне по-сути дела безразлично что делает прерывания.
Хмм... стыдно, конечно, надо, наверное, было сказать что-то типа "ага", но я не знаю, что это такое...
DAL это Database Abstraction Layer. А если по русски - уровень абстракции базы данных. Это то, что позволяет скрипту не заботиться о том, с каким типом СУБД приходится работать. Заметь. В моём коде нет mysql_query, у меня просто query. Вот представь, завтра твой хостер скажет, что mysql больше не поддерживается, юзайте postrge. Что будешь делать? менять все mysql_connect на pg_connect ? а не сложно ли это? Случись такое со мной (тфу, тфу , тфу) - я просто переобъявлю константу dbms. Мой DAL содержит отдельный код, для каждого типа БД. Т.е. есть класс для работы с Mysql, есть для работы с MsSQL. Есть ещё класс переходник. В результате я получаю 1 единственный объект $db - с, всегда постоянным, набором функций.
Ну... я могу ещё долго рассказывать, ну закончим на этом
Но мне почему то кажется, что и шаблонизатора у тебя нет. Верно?
Вот пример шаблонов:
http://bbs.vbstreets.ru/templates/subSilver/посмотри файлы - это шаблоны. Если у тебя такого нет, значит и шаблонизатора нет тоже.
(Судя по слелующим твоим словам, я почти понял что у тебя его нет).
Могу объяснить что это.
1) верхняя шапка
2) реклама
3) меню
4) левая менюшка (вместе со сценарием)
5) правая менюшка (вместе со сценарием)
6) копирайт
Центровушка выполняется в зависимости от id или sort
Я скажу так... никто не запрещает делать так (как у тебя). Но лучше подключать файлы по их функциональности, а не по контенту. Т.е. отдельно файл для работы с БД. Отдельно файл для подсчёта статистики.
Хакер, очень тебя прошу, если это убого, и я полный кретин, скажи в чем!!! Подскажи, как лучше, ты же знаешь, не держи в себе...
Убого... убого, но ты не кретин. Ты просто новичок, ты не знаешь.
Я тоже был таким, я тоже спрашивал, как в php склеить две строчки? + не помогает. Вот собственно, я и подсказал.
Надеюсь, мои слова как то подействуют на тебя. У меня есть, на мой взгляд, достаточный опыт, чтобы советовать. Видишь ли, всё вышеописанное делается мной в данный момент.
Я уже 6 месяцев делаю один крупный и сложный сайт (да-да,
AjaxVS, можешь злорадствовать сколько хочешь).
Всё что я описал, всё это я реализовал в нём. На все эти умные системы я потратил 2 месяца - да, было сложно... да, было скучер писать сотни строк кода, неделями, не имея возможности наблюдать прогресс в разработке сайта. Я писал какой-то код, который придумывался на ходу. Я не знал, будет ли он работать, и как. Меня спрашивали - как прогресс с сайтом, и мне было стыдно говорить, что ни одной страницы не сделано. Но оно того стоило. Сейчас я создаю страницы "в 2 клика". Главная страница, в которой напиханнно море инфы, занимает примерно где то 80 строчек. И также с остальными страницам. Делать выводы тебе
- спросишь ты.