Комментарии 50
>За это время я написал довольно большое количество проектов
Не в упрек, но за год, все что в основном пишется это не проекты, это старт :)
>Стоит ли бороться с отделением логики
В большинстве случаев стоит, разницы нет как это выглядит.
>Необходимо ли держать статусы ошибок…
Если система мультиязычная, с возможностью правки текста ошибки то в бд, а если нет то нет смысла.
># В каких случаях имеет смысл использовать одно поле в таблице MySQL, но с несколькими значениями, разделенными например | или &.?..
Ну предположим, если мы считываем один раз всю строку и с ней работаем, то можно и через разделитель хранить, а если мы захотим искать по данным, которые в этой строке, то ни в коем случае.
Не в упрек, но за год, все что в основном пишется это не проекты, это старт :)
>Стоит ли бороться с отделением логики
В большинстве случаев стоит, разницы нет как это выглядит.
>Необходимо ли держать статусы ошибок…
Если система мультиязычная, с возможностью правки текста ошибки то в бд, а если нет то нет смысла.
># В каких случаях имеет смысл использовать одно поле в таблице MySQL, но с несколькими значениями, разделенными например | или &.?..
Ну предположим, если мы считываем один раз всю строку и с ней работаем, то можно и через разделитель хранить, а если мы захотим искать по данным, которые в этой строке, то ни в коем случае.
Насчет разделителей:
В случае если мы имеем список фотографий одного пользователя, решением в лоб вижу запись в поле `foto` таблицы `users` через разделители список названий фотографий. Решение как я понимаю сработает быстрее чем создание дополнительной таблицы и занесение туда каждой фотографии.
Как бы Вы это решили? Например для среднего проекта в 1000 пользователей / сутки (ориентация проекта — отнють не фотографии, однако они необходимы)
В случае если мы имеем список фотографий одного пользователя, решением в лоб вижу запись в поле `foto` таблицы `users` через разделители список названий фотографий. Решение как я понимаю сработает быстрее чем создание дополнительной таблицы и занесение туда каждой фотографии.
Как бы Вы это решили? Например для среднего проекта в 1000 пользователей / сутки (ориентация проекта — отнють не фотографии, однако они необходимы)
>решением в лоб
Сразу отсекаем
>Решение как я понимаю сработает быстрее
Это на первый взгляд, а если нужно удалить фотографию, а она в центре текстового поля на 1000 символом.Проблем несколько.
а)выделить разумную длину поля, в вашем случае не понятна какая длинна.
б)работать со строками в запросах типа SUBSRING очень накладно, скорость запроса падает в 2-5 раз.
в)не удобное обращение/изменение значения в строке
Сразу отсекаем
>Решение как я понимаю сработает быстрее
Это на первый взгляд, а если нужно удалить фотографию, а она в центре текстового поля на 1000 символом.Проблем несколько.
а)выделить разумную длину поля, в вашем случае не понятна какая длинна.
б)работать со строками в запросах типа SUBSRING очень накладно, скорость запроса падает в 2-5 раз.
в)не удобное обращение/изменение значения в строке
А чтобы изменить название нужно разбирать массивы и собирать их обратно? А если добавляется еще одно поле (размер), то чего делаем?
Да, вижу с разделителями я многократно погорячился :/
Получается хранить в одном поле адреса вида /profile/121/56/ тоже глупо,
так как при малейшем изменении прийдется регэкспами перелопатить все таблицы.
Получается хранить в одном поле адреса вида /profile/121/56/ тоже глупо,
так как при малейшем изменении прийдется регэкспами перелопатить все таблицы.
решением в лоб вижу запись в поле `foto` таблицы `users`
Думаю, легче добавить к таблице `foto` поле `user` с id пользователя, которому принадлежит фотография =)
Ниже неоднократно советовали покопаться в исходниках какого-то готового проекта. От себя добавлю — разберитесь в каком-либо MVC-фреймворке — многое узнаете о разделении отображения и логики, приемах работы с БД и обслуживании ошибок. Будет ещё лучше, если в этом фреймворке будет ORM — познакомитесь с более правильным подходом к построению БД.
Думаю, легче добавить к таблице `foto` поле `user` с id пользователя, которому принадлежит фотография =)
Ниже неоднократно советовали покопаться в исходниках какого-то готового проекта. От себя добавлю — разберитесь в каком-либо MVC-фреймворке — многое узнаете о разделении отображения и логики, приемах работы с БД и обслуживании ошибок. Будет ещё лучше, если в этом фреймворке будет ORM — познакомитесь с более правильным подходом к построению БД.
Как по мне, года было маловато для вынесения каких либо выводов.
Необходимо использовать библиотеки для работы с MySQL, или достаточно использовать mysql_connect, mysql_query?..
я пытаюсь отделять логику от содержания путем самописных шаблонизаторов как smarty, однако всеравно хочется в итоге создавать более масштабируемые проекты с грамотными структурами.Думается, автору стоит глянуть в сторону, например, CodeIgniter :)
В сухих мануалах я не могу найти информации, как оптимальнее организовать мой кодДля этого нужно уделять больше внимания разбору уже готовых популярных проектов и делать для себя полезные выводы.
По-моему лучше всего опыт получать от более опытных коллег, либо копаясь в уже созданном коде.
В каких случаях имеет смысл использовать одно поле в таблице MySQL, но с несколькими значениями, разделенными например | или &. ?..
Если у тебя есть массив информации, структура которого заранее неизвестно, либо его просто удобнее полностью хранить в одном поле бд, можно использовать serialize. Конечно же ни о каком поиске в таком случае речи не идет.
# Стоит ли бороться с отделением логики от отображения в php, или приемлимо допускать небольшую смесь?
Хорошо бы вырабатывать привычку жестко отделять логику от представления + обязательно поддерживать структуру в модулях… Чтобы потом не вышло что чтобы расширить фильтрацию стульев на пару полей пришлось переписывать половину сайта)
В каких случаях имеет смысл использовать одно поле в таблице MySQL, но с несколькими значениями, разделенными например | или &. ?..
Если у тебя есть массив информации, структура которого заранее неизвестно, либо его просто удобнее полностью хранить в одном поле бд, можно использовать serialize. Конечно же ни о каком поиске в таком случае речи не идет.
# Стоит ли бороться с отделением логики от отображения в php, или приемлимо допускать небольшую смесь?
Хорошо бы вырабатывать привычку жестко отделять логику от представления + обязательно поддерживать структуру в модулях… Чтобы потом не вышло что чтобы расширить фильтрацию стульев на пару полей пришлось переписывать половину сайта)
В каких случаях имеет смысл использовать одно поле в таблице MySQL, но с несколькими значениями, разделенными например | или &. ?..Есть еще один вариант — json
Я чаще всего пытаюсь отдели логику от представления на примитивном уровне.
Что то вроде:
<?
//выборки из mysql и вычисления
?>
И отдельным файлом отображение:
<? while ($assoc = mysql_fetch_assoc($select['users'])) { ?>
<? echo $assoc['name']; ?>
<? } ?>
Какие могут быть проблеммы в таком подходе?
Что то вроде:
<?
//выборки из mysql и вычисления
?>
И отдельным файлом отображение:
<? while ($assoc = mysql_fetch_assoc($select['users'])) { ?>
<? echo $assoc['name']; ?>
<? } ?>
Какие могут быть проблеммы в таком подходе?
хабра редактор съел table ,tr и td :(
В общем принцип что все циклы, и некоторые условия содержаться в файле шаблона.
В общем принцип что все циклы, и некоторые условия содержаться в файле шаблона.
А где же тут отделение? если в echo присутствует, вам нужно на отдельные файлы разбить, логика никогда не выводит информацию на экран.
Дальше $assoc = mysql_fetch_assoc($select['users'])
а connection то живой еще и вы используете базу, логика получает все данные, а представление — выводит, он никак не обрабатывает
Дальше $assoc = mysql_fetch_assoc($select['users'])
а connection то живой еще и вы используете базу, логика получает все данные, а представление — выводит, он никак не обрабатывает
Если записать в массив из mysql_fetch_assoc а в отдельном файле вывод с помощью foreach сделать, будет правильнее?
Вот пример:
pastebin.ru/301741
Вот пример:
pastebin.ru/301741
Верно. Смысл в том, что вы не держите соединение открытым, пока работает echo, ведь вывод данных одно из самых долгих процессов на странице.
При таком подходе увеличивается потребление оперативной памяти, а разрывать соединение с базой тоже плохо вариант дольше ведь могут идти еще запросы.
Мораль: нужно сначала сделать все выборки, разорвать соединение и после этого уже что-либо выводить.
P.s. Тоже советую посмотреть хороший фреймворк (от себя советую CI, как очень простой и удобный, и отлично документированный) и хороший проект на фреймворке (потому что можно взять отличный fw и убить все его достоинства уродливым использованием).
P.s. Тоже советую посмотреть хороший фреймворк (от себя советую CI, как очень простой и удобный, и отлично документированный) и хороший проект на фреймворке (потому что можно взять отличный fw и убить все его достоинства уродливым использованием).
Я как понял это маленький кусок большого кода. Но речь ведь не об этом, а о том что надо смотреть по ситуации и что лучше. А если выборка большая объём данных большой не какой оперативке не хватит.
Я так в обще с начало все накапливаю в буфер а потом все от даю клиенту. По этому в данном случае с начало все переносить в массив, а потом его обрабатывать, получится в два раза медленней( два прохода). Так что еще раз повторяю это в зависимости от ситуации а то сейчас тут на советуете и человек подумает что этот вариант единственно правильный.
PS: Смотрел я FW и CodeInteger конечно не плохой но есть в нем, что то что не устраивает. Я вот тут наткнулся на www.yiiframework.com/doc/guide/ru/quickstart.what-is-yii и мне его структура больше понравилась правда его я еще не использовал так что на счет качества не знаю.
Я так в обще с начало все накапливаю в буфер а потом все от даю клиенту. По этому в данном случае с начало все переносить в массив, а потом его обрабатывать, получится в два раза медленней( два прохода). Так что еще раз повторяю это в зависимости от ситуации а то сейчас тут на советуете и человек подумает что этот вариант единственно правильный.
PS: Смотрел я FW и CodeInteger конечно не плохой но есть в нем, что то что не устраивает. Я вот тут наткнулся на www.yiiframework.com/doc/guide/ru/quickstart.what-is-yii и мне его структура больше понравилась правда его я еще не использовал так что на счет качества не знаю.
Давай-те говорить за конкретные случаи, автор ведь привел именно маленький код, отделяя логику в отдельный файл, естественно подключение к базе открывается к примеру в начале, а закрывается в конце файла, после полной выборки нужных данных.
>Необходимо использовать библиотеки для работы с MySQL, или достаточно использовать mysql_connect, mysql_query?..
Не необходимо, но желательно.
Плюсы:
— улучшается читаемость запросов.
— запросы защищены от SQL инъекций(смотри prepared statements)
— возможно доработки под себя
— улучшенный контроль ошибок *
* Это я о PDOExceptions — очень удобно.
Минусы:
— производительность немного падает*
*при использовании нативного расширения PDO действительно немного (3-10%), при использовании сторонних библиотек возможно значительное падение производительности
Я обеими руками за PDO, и удобен, и работает быстро.
Не необходимо, но желательно.
Плюсы:
— улучшается читаемость запросов.
— запросы защищены от SQL инъекций(смотри prepared statements)
— возможно доработки под себя
— улучшенный контроль ошибок *
* Это я о PDOExceptions — очень удобно.
Минусы:
— производительность немного падает*
*при использовании нативного расширения PDO действительно немного (3-10%), при использовании сторонних библиотек возможно значительное падение производительности
Я обеими руками за PDO, и удобен, и работает быстро.
Да, библиотеки меня как раз заинтересовали благодаря возможности ведения логов, контроля ошибок и SQL — инъекций. Пытался сам что то написать, но не смог создать универсального решения для сложных запросов с вложенными SELECT и WHERE, и забросил это дело.
Попробую PDO.
Попробую PDO.
Можно небольшой свой велосипедик написать(особенно в начале даст понять как происходят sql injection), у меня такой класс занимает строк 100-150, для нормально приема, определения типа параметров и ихней подстановки в запрос.
например выборка из БД с последующим помещением в массив:
// подставляем вместо :colour слово red. Значение red экранируется во избежание инъекции автоматически.
$sth = $dbh->prepare(«SELECT name, colour FROM fruit WHERE colour = :colour», array (':colour => 'red'));
$sth->execute();
$result = $sth->fetchAll(PDO::FETCH_ASSOC);
$result — теперь массив который содержит выборку
в результате написал обёртку и сократил всё до одной строки
$result = $db->MyFetchFunction(«SELECT name, colour FROM fruit WHERE colour = :colour», array (':colour => 'red'), PDO::FETCH_ASSOC);
$result — теперь массив который содержит выборку
// подставляем вместо :colour слово red. Значение red экранируется во избежание инъекции автоматически.
$sth = $dbh->prepare(«SELECT name, colour FROM fruit WHERE colour = :colour», array (':colour => 'red'));
$sth->execute();
$result = $sth->fetchAll(PDO::FETCH_ASSOC);
$result — теперь массив который содержит выборку
в результате написал обёртку и сократил всё до одной строки
$result = $db->MyFetchFunction(«SELECT name, colour FROM fruit WHERE colour = :colour», array (':colour => 'red'), PDO::FETCH_ASSOC);
$result — теперь массив который содержит выборку
Мне очень нравится goDB. Кто-нибудь поделится опытом его использования?
НЛО прилетело и опубликовало эту надпись здесь
Сделайте меня развидеть это!
может быть стоит посмотреть на другие проекты, ЯП и фреймворки для того, чтобы получить ответы на многие вопросы?
Я бы советовал вам посмотреть в сторону Open Source framework-ов. Например: ZendFramework, Symphony, CakePHP и т.д. — там можно подчерпнуть множество тонкостей реализации и архитектуры.
Сильно советую почитать «Structure and interpretation of computer programs» и «How to design programs» (и упражнения поделать, обязательно!).
Изучению MySQL/PHP/etc (какую-то конкретную технологию/ЯП) конечно же стоит уделять какое-то внимание, но во главу угла их ставить нельзя, это ведет к «туннельному зрению» (tunnel vision), к принятию чего-то за догму («PHP отличный ЯП!», «PHP сосет!», etc.), ну и проч.
Изучению MySQL/PHP/etc (какую-то конкретную технологию/ЯП) конечно же стоит уделять какое-то внимание, но во главу угла их ставить нельзя, это ведет к «туннельному зрению» (tunnel vision), к принятию чего-то за догму («PHP отличный ЯП!», «PHP сосет!», etc.), ну и проч.
Мой совет, начать изучать python и Django.
Хороший framework на хорошем языке.
Ни один из моих знакомых который перешел на данную связку с пхп, обратно на php не вернулся.
Можно много писать о преимуществах языках и платформы, но лучше попробуйте сами, благо и джанго и питон хорошо документированы.
Хороший framework на хорошем языке.
Ни один из моих знакомых который перешел на данную связку с пхп, обратно на php не вернулся.
Можно много писать о преимуществах языках и платформы, но лучше попробуйте сами, благо и джанго и питон хорошо документированы.
Я вернулся на PHP после того как год писал на Python + ранней версии Django, в те времена, когда мы с тобой работали в одной компании.
Всё же, хоть и есть хейтеры у PHP, но на нём написано очень много кода, который можно переиспользовать.
И PHP 8 неплох, но мне больше нравится язык программирования Rust.
Мой совет, учить Rust, пригодится.
Всё же, хоть и есть хейтеры у PHP, но на нём написано очень много кода, который можно переиспользовать.
И PHP 8 неплох, но мне больше нравится язык программирования Rust.
Мой совет, учить Rust, пригодится.
* Необходимо использовать библиотеки для работы с MySQL, или достаточно использовать mysql_connect, mysql_query?..
* В каких случаях имеет смысл использовать одно поле в таблице MySQL, но с несколькими значениями, разделенными например | или &.?..
* Необходимо ли держать статусы ошибок (для сообщений посетителю) в php, или лучше их запрашивать из MySQL?
* Стоит ли бороться с отделением логики от отображения в php, или приемлимо допускать небольшую смесь?
* Необходимо использовать библиотеки для работы с MySQL, или достаточно использовать mysql_connect, mysql_query?..
* В каких случаях имеет смысл использовать одно поле в таблице MySQL, но с несколькими значениями, разделенными например | или &.?..
* Необходимо ли держать статусы ошибок (для сообщений посетителю) в php, или лучше их запрашивать из MySQL?
* Стоит ли бороться с отделением логики от отображения в php, или приемлимо допускать небольшую смесь?
* Необходимо использовать библиотеки для работы с MySQL, или достаточно использовать mysql_connect, mysql_query?..
* В каких случаях имеет смысл использовать одно поле в таблице MySQL, но с несколькими значениями, разделенными например | или &.?..
* Необходимо ли держать статусы ошибок (для сообщений посетителю) в php, или лучше их запрашивать из MySQL?
* Стоит ли бороться с отделением логики от отображения в php, или приемлимо допускать небольшую смесь?
* Необходимо использовать библиотеки для работы с MySQL, или достаточно использовать mysql_connect, mysql_query?..
Зависит от поставленной задачи, нужно ли вам mysql, mysqli или pdo_mysql.
* В каких случаях имеет смысл использовать одно поле в таблице MySQL, но с несколькими значениями, разделенными например | или &. ?..
Такого случая не существует
* Необходимо ли держать статусы ошибок (для сообщений посетителю) в php, или лучше их запрашивать из MySQL ?
Лучше всего в конфигуарционном файле. Опять же это зависит от поставленной задачи, но MySQL, мягко говоря, не самый лучший вариант.
* Стоит ли бороться с отделением логики от отображения в php, или приемлимо допускать небольшую смесь?
Если вы уже начали задумываться о таких вещах, то по советую вам изучить какой нибудь MVC фрэймворк, например, ZF ну или на крайняк Symphony. Одним словом бороться или нет, зависет от части приложения, куда вы ее пишете.
Случалось ли с Вами подобное?
Стоит найти учителя или всё прийдет с опытом?
Я дико извиняют, что накакал — случилось какая то мне не понятная хрень
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Спустя год изучения PHP