sKaa
Да, версия 5.3.10... но если посыпятся ошибки, их вывод спрятать проще
Zuldek
Данная ошибка уже исправлена, ибо нужно было, что бы люди могли работать. В первом посте я писал о том, что я хочу "вернуть поведение интерпретатора как было" потому, что опасаюсь подобных багов в других местах, т.е. с другими функциями... Естественно исправить эту опечатку, добавив 0 - это мелочь по времени. А вот отдебагать подобный код в большой и хитрой функции - сложнее.
Я бы не подумал и здесь на строку с mysql_result, если бы сама функция не была на 2 строчки... и там просто больше нечему было багать.
master_alf ну да...бд кэширует результат в памяти
однако и фс тоже это делает
тут хз...мерить надо наверное
Я одно время так же задавался очень сильно вопросом оптимизации кода, когда количество стало переходить в качество... и один опытный товарищ, у которого я часто консультировался, процитировал мне кого-то из именитых программистов. "Если бы на первом месте стояла экономия ресурсов, то мы бы до сих пор все писали только на Си". Всё-таки такие языки как PHP, созданы не для ОМГ быстроты, а для удобства и скорости разработки. Я бы исходил из этого. Выигрыш в наносекунду - это, конечно, хорошо, но когда на то, что бы понять "а будет ли здесь этот выигрыш" тратится несколько дней на обсуждение - думаю, это бесполезно. Когда оба варианты достаточно хороши, лучше использовать тот, который будет более читабельным и удобным в данном контексте. Вот мое мнение.
Данные в БД хранятся, естественно, в виде файлов на винте. Но в БД есть внутренний кэш, часть данных хранится в оперативной памяти и т.д. Иначе зачем вся эта надстройка в виде Сервера БД над файлами, где данные хранятся? Для удобства и оперативной работы, не так ли?
Про параметры - понятно, возможно, тогда, различие в самих версиях PHP... Значит придется ждать появления возможных багов да фиксить...
Код же приводить в порядок не просто лень, а не целесообразно. Гораздо быстрее переписать с нуля, чем разгребать эти завалы. Опыта не было вообще, ни в ООП, ни в MVC, который не соблюдал, ни в других полезных штуках, которые делают код правильным.
Но есть другие задачи, которые нельзя отложить на исправление программы которая работает, но "внутри всё не красиво". Потому временно приходится искать костыли. Я не любитель говнокода, то были "ошибки молодости". Просто переписать нет времени.
Дык я уже пофиксил, сейчас этот кусок работает. Но хотелось бы, что б работал старый вариант, т.к. неизвестно сколько еще подобных глупостей я допустил... и, если с логина всё начинается, и там баг видно сразу, то некоторые могут проявляться в таких... хитрых случаях, что будет кучка гемора в работе с базой, и с поимкой этих багов...
Я тоже подозреваю, что поле интерпретировалось как индекс... но почему оно перестало работать на новом серваке?.. вопрос-то собственно в этом. Хотелось бы "вернуть как было", что б свой срок просто база доработала с той отлаженной логикой, которая была и проверена временем. А то если полезут новые косяки... я рехнусь их разгребать.
ИМХО, чтение из файла при каждой загрузке страницы - это сомнительный выигрышь. Даже если функция чтения быстрее, чем получение данных из БД, лишние обращения к винту, по идее, не есть гут. А если кэшировать результат и держать его, до изменения данных в файле - не всё ли равно, откуда они будут браться один раз? При таком раскладе, если весь остальной контент берется из базы, мне кажется нецелесообразным хранить новости в файле.
Приветствую.
Вопрос у меня довольно странный... потому придется сначала небольшое вступление написать.
Пару лет назад была необходимость написать базу данных, программировать тогда я не умел. Совсем. Опыт был "в школе на дельфях"... так что уровень сами понимаете. PHP не знал... в общем писал как получится. Потому всё работает, но уже давно "не понятно как". Намедни умер сервер, и при его восстановлении у меня теперь новая версия PHP, перенес я старую базу, и вдруг вылез первый косяк - пользователи не могли пройти авторизацию. Дебагинг показал где проблема. Мой код, который работал раньше, выглядит вот так:
Т.е. у меня был пропущен второй обязательный параметр функции mysql_result (индекс строки) - глянув на документацию я крайне удивился, как оно вообще работало ... но факт есть факт - работало! И сейчас на локальной машине - работает...
А вот и сам вопрос: Что можно сделать, что бы заставить эту функцию работать как раньше - с нарушением документации?
Понимаю, что это плохо, что за это надо бить по рукам и т.д. Но база написана криво, править её - бред. Там нужно просто писать по-новой. И сейчас не известно где еще какие косяки могут повылазить... исправлять по всему коду вызов mysql_result - конечно можно, но нет гарантии, что это единственная функция, где я так накосячил... В общем - есть ли у вас, господа, идеи, в чем причина работоспособности подобной опечатки?
Всегда, когда я вызывал mysql_result - была одна строка в результате mysql. Я так подозреваю, что где-то в PHP.ini стоял какой-то параметр, из-за которого всё работало. Есть ли варианты куда копать?
У меня сложность была именно с тем, как из данных полученных от БД, слепить объект в котором у каждой фирмы будет в свойствах полностью вся история по всем товарам.
В итоге сделал через массивы, тему можно закрывать.
Всем спасибо, кто помогал.
Фирма_1, Фирма_2 это тоже что и "ключик в куках 1", "ключик в куках 2"
Но в таком случае я не получу статистику по всем фирмам, я получу по одной конкретной. А мне нужно список по всем фирмам.
Если я буду использовать фирму в WHERE, то мне нужно делать кучу запросов.
Согласен, пример очень похож.
Только в Вашем случае просто выводится все, что было приобретено конкретным пользователем. Грубо говоря получается одномерная таблица... т.е. просто список.
1ый товар
2ой товар
3ий товар
Мне нужно получить таблицу вида
Название | товар 1 | товар 2| товар 3|
Фирма_1 | 3шт | 0 шт | 2 шт |
Фирма_2 | 1шт | 2 шт | 0 шт |
При Вашей же реализации получится что-то вроде
Фирма_1 | 3шт
Фирма_1 | 0шт
Фирма_1 | 2шт
Вот из-за этого и весь мой велосипед придумывается.
Что касается использования массивов вместо классов. Думаю и правда это разумнее, экономичнее и оптимальнее... Но я сейчас только изучаю ООП, потому в данном учебном проекте решаю задачи через него.
$items->cl_name = new stdClass;
$items->cl_name = $row->cl_name;
А теперь задумайтесь, что вы этим сделали.
Как я понимаю - глупость
Только не уверен почему... Но Ваш совет я понял именно так >_<
Наверное, тип объекта перезаписывается при присваивании значения из свойства другого объекта?..
DeepVarvar пишет:
Сделайте DB так чтобы он мог принять запрос и вернуть массив результата..
Я, конечно, могу получить данные в виде массива, но каким образом я смогу слепить такой объект, как мне нужен - так и не пойму. (Добавление)
DeepVarvar пишет:
Прочтите то что я написал выше и еще выше (оба сообщения).
Сообщения прочел сразу, но для начала решил более точно описать, что же мне нужно.
Про __set и __get не читал, сейчас ознакомлюсь.
Спасибо за совет.
В базе хранится история продаж, в трех разных таблицах.
Кто купил, что купил, и когда купил.
Мне нужно сделать сводный отчет вида:
"Компания №1 купила товар №2 (кол-во), товар №3(кол-во), товар№4(кол-во) и т.д.", и для наглядности нужно это все расчертить красивой таблицей.
Я делаю запрос к базе и получаю по каждой компании данные.
Но в одной строке результата я получаю данные по одному виду товаров для компании. Соответственно если я так же и буду выводить, то у меня получиться не наглядная таблица.
Будет что-то вроде
"Компания №1 товар №2
Компания №1 товар №3
Компания №1 товар №4"...
Что бы от этого уйти, мне нужно из строк результата MySQL свести данные воедино.
Т.е. получить структуру примерно следующего вида:
$obj(компания)->tovar_id(цифра товара)->count(количество проданного)
И уже в результирующей таблице я сделаю нужный вывод информации.
Вот и вопрос, собственно, каким образом я могу сделать нужный мне вид объекта?
while($row=mysql_fetch_object($tempQRY)){//в цикле заполняем результирующий объект нужными данными.
$obj->{$row->tovar_id}=$row->tovar_id
$obj->{$row->tovar_id}->count=$row->count
}
return$obj;
Логика вот такая. При таком раскладе объект должен бы заполняться правильным образом, т.е. не будут дублироваться покупатели, и по каждому покупателю будет полностью заполнена вся его история...
но как правильно исполнить эту запись? вот чего понять не могу
P.S.Сори за объем, но кратко объяснить у меня не получилось.
Главная
Помощь
Поиск
Пользователи
Найдено сообщений: 19
