Не в тему, но умолчать не смог.
Так код писать нельзя. Все в одну колонку, можно и в строчу таким макаром писать!
Модераторы накажите меня если я не прав!
Есть MS OLAP к которому юзера ходят через Excel.
Не нравится мне это хочу что бы ходили к нему через WEB.
На корпоративном портале генерировали запросы, портал слал запросы к MS OLAP (analysis services) и результат представлял в табличной форме.
Отсюда нужно что то типа библиотек которые умеют подцепляться к OLAP и тягать данные.
Поиск по большому счету ничего не дал.
Если кто встречался, ткните носом куда копать.
Есть внутренний сайтик в кодировки UTF8
Делаю запрос http://portal/drilldown.php?acti[dot][dot][dot]ationId=роз_СБор
Все замечательно пока живу на Ubuntu
Как только запрос приходит с виндовой машины, кодировка запроса не UTF8 а Win1251
Получается что я получаю запрос в неизвестной кодировке фактически
Что с этим делать и как быть?
Скажите пожалуйста нужно ли мне углубляться в ооп или достаточно просто испльзовать функции?
Просто хочеться как то дальше повышать свои знания.
Вопрос философски, как ты привык и тебе удобно так и пиши.
Я пришел в веб из ООП, посему пользую ООП. Другие предпочитают процедурность ...
По любому нужно по крайне мере буть знакомым и уметь понимать. Закачаешь ты себе библиотечку на ООП, и нужно будет знать что да как
А значения по-умолчанию для чего ещё даны? Это-то как раз не сложно сделать.
Это совсем не одно и тоже
Мелкий пишет:
Да, это не самый верный вариант, но, в некоторых случаях единственный возможный. А в случае класса, реализующего соединение с БД, наоборот, указание БД по-умолчанию, такое же логичное действие, как и указание пользователя, хоста, пароля соединения. Или же, нелогичное, т.к. тогда не видно, куда коннектится и под чьим именем скрипт. Может он под рутовым пользователем сидит в базе?
Как это под рутовым, кто его пустил то туда
База по умолчанию нужна, в 90% она еинственная.
По уму в ООП реализуется статическое свойство класса.
В PHP я думаю нужно реалиовать глобальную функцию currentDB().
Мелкий пишет:
А ведь всё равно надо будет шерстить скрипты при изменении имени БД, хоть для указания set_db($db);, хоть для запросов.
Либо, аналогично, тянуть переменную с именем вторичной БД и вставлять это имя в запросы через обычную конкатенацию.
Ну батенька, я про абстракцию иное имел ввиду.
Вот вы содали класс который занимается форматирование вывода, ему скормили dataset (или наследника) и даже не паритесь что а БД. А то что если у вас что то кардинально меняется то код менять придется .. от ентого ничего не избавит
Не очень... Зачем писать кучу кода, который ещё и выполняться будет, отнимая ресурсы, для достаточно постоянной СУБД?
Опять же потому что СУБД может меняться и ГЛАВНОЕ для прозрачности кода и его четкой структуры
Мелкий пишет:
Ну потому и пишу "де-факто" ;) В далёком 2002 (когда выпустили под линуха делфю) году у меня не то, что линуха не стояло, вообще ПК не было
А знаете сколько с тех пор именилось Достаточно постоянные быза мхом порасли
Мелкий пишет:
Вот, примерно это и спрашивал. Если отдавать заботиться о экранировании и проверке данных на корректность единожды написанному методу, то это уже неплохой повод использовать такие классы. Правда, если они при этом не потребляют ресурсов в пару раз больше всего скрипта
А то по первому сообщению данной возможности не было видно.
Ну я же не писал и то что dataset может иметь наседников, а это реально воможно.
Мелкий пишет:
И по самому классу:
Я так понимаю, что конструктор инициализирует соединение с БД по дефолтным значениям, определённым в классе?
А $db->set_params($dbhost, $dbname, $dbuser, $dbpasswd, "utf8"); - просто возможность сделать коннект к другой базе? А почему бы не передавать эти данные сразу конструктору, чтобы класс не создавал дважды соединение?
Почему бы закрытие соединения не вынести в метод __destruct? Тогда будет закрываться самостоятельно. (или я плохо понимаю, когда этот метод вызывается?)
Выбор БД я бы определил тоже по-умолчанию, т.к. в рамках 1 проекта БД меняется не слишком часто и в крайнем можно обратиться к ней по полному имени - т.е. база.таблица.имя_поля
Вообще по уму нужно 2 конструктора, пустой и с параметрами, но к сожалению PHP это не поддерживает. Создайте наседника который имел тот конструктор который вам нужен
Про деструктор, может быть вы и правы, но нужно иметь "насильный" метод тоже
Баа.таблица - плохой вариант, потому что не таблица а запрос!
Кроме того это нарушает принцип абстракции, апрос независит от БД
P.S.
Извиняюсь за орфографию, клавиатура умирает потихоньку
Есть 5 полей в таблице, эти поля могут обновляться в произвольном порядке (не по порядку)
подскажите, возможно ли узнать какое поле обновлялось последним?
Не совсем понятно что имелось ввиду, но попытаюсь ответить.
Согластно реляционной логики запись обновляется целиком, соотвественно какое и полей обновено последним сервер знать не может. Грубо говоря можно несколько полей за раз обновить. Посему возлагать эту функцию на mySQL бесполезно.
Я бы добавил поле еще одно в которе бы записывал средстваи PHP последнее именяемое поле. (По правде можно тригир писать на SQL (не уверен для mySQL) но это уж черезчур ;) )
И раз уж пошла така пьянка, я подозреваю что вы нарушаете какую либо из форм нормализации БД, поля ваши должны быть не колонками а строками скорее всего.
// Также по полю id должен быть создан уникальный индекс.
if(!@$DB->query('INSERT INTO tbl(id, field) VALUES(1, ?)',$field)){
// Здесь идет реакция на ошибку, если она возникла.
// Контекст ошибки можно получить через $DB->error.
$DB->query('UPDATE tbl SET field=? WHERE id=1',$field);
}
Сточки зрения ООП надо было бы задать свойство базе данных, не сообщать об ошибках. В этом случае код становиться более читабельным и понятным.
$DB->IgnoreError = ....
А если серьезно то вообще ошибку в try catch перехватывать
Мелкий пишет:
eai пишет:
Кроме того такая структура поволяет сделать код портабельным между различными SQL серверами
Вот только разве что. Но, это надо учитывать уже на этапе создания запросов.
А не проще ли просто возложить разницу трактовки запросов на обертку?
Мелкий пишет:
eai пишет:
Почему вообще необходимо использовать ООП?
Необходимо? Ни в коем случае не необходимость. Использовать нужно только наиболее подходящие методы.
Страуструп токачто поперхнулся . Идиологический спор. Для сторонников процедурного программирования все что я пишу полная ахинея, им я доказывать ничего ен собираюсь, они просто идут иным путем и все. Все что я написал только для тех кто любит ООП
Мелкий пишет:
eai пишет:
Почему на дельфях прямые выовы не испольуются?
Не знаю, меня объектный паскаль, а тем более де-факто только виндовый, не интересует.
Ну не тока виндовый, они делали сие для линукс, но ен пошо в массы, не нашо спроса к сожалению. Они делают уровни абстракции как раз для унификации кода и его легой читаемости. VB тож самое
P.S.
Специаьно и написал так что бы носом тыкать начали (Добавление)
Мелкий пишет:
И заодно чем оно всё лучше стандартных функций mysql_*?
Можно просто кодом.
Стандартные функции плохо вписываются в ОО модель и код на них получается не прозрачный. Можно и с ними (собственно говоря долго жил и так) но копаться в котде потом сложнее.
Почему на дельфях прямые выовы не испольуются?
Почему вообще необходимо использовать ООП?
Кроме того такая структура поволяет сделать код портабельным между различными SQL серверами (Добавление)
PDO - что то надо ставить, не камельфо, не везде стоит
DbSimple - интересно, нашел бы раньше испольовал бы, но все же это стиль PHP а не ООП
MDB2 - опять же надо что то инстаировать , не каждый хостер согласиться
Тут кстати на DbSimple написали
Чем неудобны другие библиотеки
* PEAR DB, ADOdb: библиотеки не упрощают работу с СУБД, они просто предоставляют единый (и многословный) интерфейс; отладочные возможности в зачаточном состоянии.
* PDO: требует PHP 5; неудобная работа с placeholder-ами и результатами выборки.
* Стандартные функции PHP для работы с СУБД: низкая читабельность кода, значительные неудобства в отладке, подверженность уязвимостям вида SQL Injection.
Главная
Помощь
Поиск
Пользователи
Найдено сообщений: 520
