Вы не зашли.
на чет mysqli не уверен, но в PDO как минимум в обрамлении кавычками разница при указании параметра как int или string.
bind_param - попробуй, с ходу не скажу, т.к. mysqli не использую.
Пока решил, что не стоит в это лезть
Кстати, плохо ли то, что я передаю объект с соединением mysqli во все модели, или объекты передаются по ссылке? (вот никак не могу вспомнить)
Желание стать программистом из-за того, что вам нравляться компьютерные игры-это все равно, что желание стать гинекологом из-за того, что вам нравиться секс
модель работы с бд хорошо ложится на логику синглтона.
т.е. получение объекта работы с бд может выглядеть как $db = DB::getInstance();
Я знаю.
Но мне совсем не сложно передавать sql в модель, это позволит, к примеру, подключится к разным базам данных.
Этот функционал у меня есть, но я его решил не использовать
Желание стать программистом из-за того, что вам нравляться компьютерные игры-это все равно, что желание стать гинекологом из-за того, что вам нравиться секс
для подключения к разным бд, мне кажется, лучше сделать что-то типа DB::getBlog(); DB::getForum();
Ладно, я понял, это все очень интересно.
_________________
Есть вот какой вопрос.
Представь, что есть таблица Users, в которой хранятся только самые важные данные - логин, пароль, хэш, емейл, к примеру.
Но есть и другие настройки пользователя, тысячи их: настройки количества постов на страницу, анкетные данные и прочее, прочее, прочее.
Казалось бы, бери да добавляй дополнительные столбчики в таблицу Users да не знай проблем.
Но:
Их могут добавлять разные модули, что само по себе проблема (вдруг в модулей совпадут названия колонок, ведь все модули не проследишь, и не смотря на соглашение о наименовании столбцов, могут найтись криворукие), а в самом ActiveRecord классе количество столбцов не динамично, а строго вписывается в файл (чтобы каждый раз не запрашивать в базы данных существующие столбцы). Я понимаю, что сам себя загнал в слегка неудобную архитектуру, при которой дописывание столбцов требует изменение файла с моделью, что при динамичных модулях становится невозможным. В принципе, решить эту проблему можно, просто переписав метод, который возвращает список столбцов для конкретной модели, заставляя список колонок брать именно с базы данных, тратя на это еще один запрос.
Как вариант я подумал, что можно создать таблицу settings с подобной структурой: id_user, module, parameter_name, parameter_value.
Это позволит любому модулю хранить свои настройки, не изменяя самой структуры главной таблицы users.
С минусов, какие мне показались - возможная потеря производительности (ведь надо запросить не одну строчку, а несколько записей с достаточно огромной таблицы).
Как ты считаешь - заниматься ли дописыванием столбцов в таблице Users, или все же лучше создать отдельную таблицу с конфигурацией пользователей, а в Users хранить самые базовые данные, которые касаются только авторизации?
Буду благодарен за твою точку зрения на этот вопрос.
Желание стать программистом из-за того, что вам нравляться компьютерные игры-это все равно, что желание стать гинекологом из-за того, что вам нравиться секс
в процессе чтения зацепилось внимание за фразу "заставляя список колонок брать именно с базы данных, тратя на это еще один запрос". но ведь эти метаданные можно и нужно кэшировать. а кэш чистить скриптом по требованию.
на счет альтернативного варианта - да, вполне вариант и производительность повышается все тем же кэшированием.
что лучше однозначно сказать мне сложно. 2 вариант, например, используется в sea. довольно удобно и расширение проходит абсолютно безболезненно. 1 вариант, по памяти вспоминаю, в других не публичных проектах. При относительно небольшом и редко меняющемся кол-ве столбцов проблем не создает, в принципе.
//Гм, о том, чтобы писать это в кеш - я даже и не подумал. Кеш имеешь в виду файловый, а по возможности - на средства типа eAccelerator или memcache?
Просто именно поэтому я и решил писать метаданные прямо в файл. Ведь модель вообще редко меняется, а для тех, которые изменяются - можно как раз и использовать кеш. Неплохая идея ведь!
Я конечно думал о кешировании, это бесспорно. Но хорошее кеширование - это memcache (не так ли?), а Армеру придется переежать на VDS. Поэтому пока что буду без него, думаю, проект справится на первых порах, а может и вообще отлично будет справлятся. Участки, которые можно кешировать - я отмечаю.
Вопрос о том, что 2 способ подходит хуже, так как настроек может быть реально много для одного пользователя. Но то, что их можно бы кешировать - отличный совет, спасибо!
//Кратко о своей модели - просто список полей возвращает определенная функция. Ей ничто не мешает запрашивать метаданные с базы или просто с кеша, но в большинстве случаев я просто возвращаю массив со списком столбцов.
Вот за это я и люблю свои велосипеды - это заставляет тебя думать над проблемами, искать их решение, а работа программиста - это как раз на 95% - решение интересных задач.
Писал бы я на готовом фреймворке - я бы об этом никогда не задумывался
Еще раз спасибо!
Желание стать программистом из-за того, что вам нравляться компьютерные игры-это все равно, что желание стать гинекологом из-за того, что вам нравиться секс
Akdmeh, ну memcache или просто файловый кэш - это уже вопрос того, сколько прослоек ты напишешь..)
Akdmeh написал:
Писал бы я на готовом фреймворке - я бы об этом никогда не задумывался
почему же не задумывался? я вот сейчас symfony ковыряю, очень даже задумываешься по ходу над техническими решениями примененными в фреймворке.
Ну ясно
Желание стать программистом из-за того, что вам нравляться компьютерные игры-это все равно, что желание стать гинекологом из-за того, что вам нравиться секс
