И должен меняться, ведь вы просите браузер делать редирект.
А как сделать на пхп редирект скрытно от браузера?
В учебнике написано что этот способ делает так что браузер даже не догадается, а на деле получается иначе. JustUserR
Вот, вот по этому учебнику и читал, видите, там и написано
JustUserR пишет:
все это происходит без участия браузера, который видит лишь конечную страницу с тем же самым URL
А на деле получается обратное - не тот же самый URL ...from.php, а другой: to.php куда и перенаправили, почему он меняется, как сделать так чтобы не менялся? в этом и заключался вопрос.
ps. Как тут написать администрации чтобы исправили баг с этим форумом, дело в том что на php.su я иногда когда захожу в какой-то раздел форума сбрасывается моё имя, как будто у меня не сохранены куки, и приветствует меня как гостя, когда же я через быстрый вход авторизуюсь то меня перенаправляют на главную страницу.. и начинай сначала... И это на разных браузерах.
Делаю по учебнику внутренний редирект, там сказано что адрес URI должен быть абсолютным, и он работает на CGI-версии php только. У меня денвер, сказали что там PHP установлен как CGI версия.
Еще сказано в учебнике что после его запуска from.php в браузерной строке так и останется, но у меня он меняется на to.php. Почему он меняется? Может у меня PHP установлен как модуль апаче, а тот кто сказал что как CGI был не прав. А так перенаправление происходит. Браузер - firefox на котором проверял.
Вот пожалуй действительно хороший совет. Напишу своё задуманное и выясню, сравню как оно по времени. А то конкретных ответов по вопросу тут так и нельзя получить, все на банальности ссылаются.. на индексы, я о них и так несколько раз читал и знаю толк, но есть уверенность что в файловой системе тоже есть индексы, т.к. в проводнике файлы в папке без проблем сортируются по разным полям и по дате создания и по имени файла, и по размерам и по другим...
Пока что одно кажется достоверным: плюс файловой системы перед субд в том что извлечение записи(файла) из первой по ключу(пути с именем файла) запросом GET (без посредника PHP) происходит как утверждается в разных статьях рунета в разы быстрее, и еще интуитивно кажется хранение текстовой информации в файлах даёт преимущества в оптимизации для поисковых систем при раскрутке сайтов.
Если мне нужно хранить данные которые редко меняются, которых мало и с которыми не придется работать в плане постоянного изменения сортировки и т.д. - то я использую файлы, все остальные случаи БД.
Вот за эту фразу спасибо - она - ближе к делу.
ALEN пишет:
Зачем изобретать велосипед
Про велосипед - я так понял вы имели ввиду реализацию файловой системы в MySQL вышеприведенной таблицей? Ладно не буду, хотя мне всегда интуитивно казалось, что допустим 100 тысяч записей в одной таблице - это нормально, а 100 тысяч файлов в одной папке на виртуальном хосте, пусть даже по 1 килобайту каждый, уже излишний напряг для файловой системы. Это подозрение из за того, что я когда провожу синхронизацию файлов у себя на компе между двумя ж. дисками, то знаю как долго составляется список синхронизируемых файлов, для веба - это уже ни в какие рамки не влезет, вот и подумал что может MySQL скорее будет.
ALEN пишет:
когда 10 человек одновременно будут править твой файл
Что же касается одновременной правки файла, то я знаю что для этого нужно блокировать файлы, как и таблицы в базе данных, если 10 чел. одновременно, ну может чуть тормознёт, но баг - не знаю.
ALEN пишет:
для большой работы нужно использовать базы данных
Базы данных используют почти все сайты, но вот мне не кажется что все из этих сайтов используют сложные запросы. В основном мне кажется простые: выборка по условию в полях, добавление записи, удаление и обновление. А ведь именно сложые запросы являются главным фактором использования как было написано в приведенной вами цитате. (Добавление)
Champion пишет:
Вообще вопросы про что лучще: БД или файлы отпадают, если азы изучены и поняты.
Ну значит нас в универе так плохо учили. Или учебники плохо написаны. Но сколько не изучаю базу данных вопрос всё еще не отпадает.
Champion пишет:
Речь о той таблице, которая описана по пунктам?
Вопрос поставлен не корректно.
Да именно - по той одной таблице. Ну то что не корректен с точки зрения русского языка не спорю, может и пропустил запятые. Но смысл такой: Никакой функционал по структурам не реализуется - уже есть файловая система и файловые функции. Так и вот, если я напишу в mysql такую таблицу, и реализую внутреннюю на MySQL файловую систему, то она будет быстрее функционировать чем реальная файловая система из пхп. И в каких случаях быстрее.
Не совсем, файловая система, с функциями для обращения к её содержимому - базе данных - файлам, папкам.
ALEN пишет:
Систе́ма управле́ния ба́зами да́нных (СУБД) — совокупность программных и лингвистических средств общего или специального назначения, обеспечивающих управление созданием и использованием баз данных.
Вот именно файловая система она и поддреживает ИСПОЛЬЗОВАНИЕ базы данных, а база данных в этом случае будет состоять из одной таблицы, записи которой - файлы и папки.
Да, она не поддерживает создание и управление, но речь здесь идёт лишь об использовании.
ALEN пишет:
Что должно является главным критерием для принятия решения в пользу использования базы данных
Из перечисленного - безусловно необходимость сложных сортировок и выборок.
Но тут речь о другом: менее главном для базы данных - о разграничении данных и несложных выборках с изменениями данных, и сложность - в рамках одной вышеприведенной таблицы.
maximushka
Как можно писать большой проект и не знать азов.
Вообще понимаешь суть использования SQL и преимущества
Основы баз данных я знаю - курс проходил в университете на факультете прикладная математика и информатика. Кроме того применял на практике MySQL с ним я написал чат. Кроме того я усердно сидел разбираясь в тонкостях MySQL включая типы таблиц, блокировки, и даже транзакции.
Поэтом вы сглупили сказав мне что я не знаю азов, во всяком случае это и оскорбительно.
А конструктивного ответа так и не дали, и именно на мой вопрос.
Создаётся типа социальной сети. Пользователи могут заливать туда и текстовый контент и любые другие файлы. Под текстовым контентом я имею ввиду сообщения, сообщений может быть очень много(особенное в чате), и длина сообщений самая разная.
Пытаюсь думать логически:
Файловая система условно говоря представляет собой упрощенную субд с одной б.д. и таблицей в ней, в которой:
1.предопределенные поля:
id_файла (первичный ключ)
локальное_имя_имя_файла (уникален в пределах папки),
контент_файла - типа BLOB(если null - то это папка а не файл)
id_папки - папки в которой он надится
время_последней_правки_файла
права_доступа
... и так далее
2.она допускает сортировку по полям(кроме контент файла),
индексы - все поля(кроме контент_файла).
3.операции манипуляции данными осуществляются путём файловых функций пхп и
обработки в пхп массивов из файлов.
С файловой системой сравнивается МySQL с той же таблицей и с SQL запросами из пхп по основным файловым функциям(получение списка файлов в папке, получение контента в файле и др..)
И в этом случае вопрос сводится к тому: какая из этих двух субд с такой таблицей работает шустрее и экономичнее(по памяти), по каким операциям и при каких размерах полей контент_файла, и колличестве записей в таблице?
Если на SQL и одним запросом, то получится весьма длинный запрос, даже представить себе страшно какой... Игра думаю не стоит свеч.
Хотя теоретически можно получить тройное декартовое произведение второй таблицы саму на себя, и там уже повыбирать по разным алиасам (таблицам) столбцы type. Однако скажу - декартово произведение не разумно для таблиц с большим числом записей.
Прикольно, уже больше суток ни одного ответа, значит никто ROLLBACK для дела в связке PHP&MySQL не использует... т.е. никому не нужен, и заморачиваться в вопросе где его применять не стоит.
Т.е. на каждый запрос открывать и закрывать соединение - это лишняя нагрузка.
я вообще соединение не закрываю, только через pconnect соединяюсь и вначале скрипта
Что такое транзакция - я разобрался, и смысл ROLLBACK тоже понятен - откат транзации.
НО.. не могу себе представить ситуацию, где бы его можно было бы целесообразно вызывать из PHP&MySQL. Я так понимаю, когда сценарий PHP заканчивает своё выполнение, то заканчивается и сеанс работы с MySQL, и вместе с ним и автоматический откат транзакции если команда COMMIT не была последней. А сценарий PHP может закончить своё выполнение либо в случае отключения питания, глюков на сервере, от исключения или ошибки в каком то запросе(но это уже программно при этом бросить исключение), значит во всех случаях когда надо откатывать транзакцию - она автоматически откатится, и зачем тогда ROLLBACK?
А если транзакция была вызвана лишь с целью что-то узнать из базы данных, и на основании этого сделать модификацию или откатить, то на мой взгляд целесообразней, начать транзакцию? образовать временные таблицы на имеющихся выполнить вычисления на временных таблицах и сделать или не сделать в соответствии с результатами модификацию,и COMMIT . Или я не прав?
Достиг желаемого на голом SQL, правда несколько тяжеловато вышло.
Значит проблема была в том, что таблицы InnoDB не поддерживают инкрементное поле в составе составного ключа, которое мне вообщем-то нужно было позарез, в обход этой ситуации я наметил такую конструкцию вставки, ведь инкремент работает при вставки:
за исключением принудительной вставки AUTO_INCREMENT поля своим значением, но если есть такая возможность, тогда зачем делать поле AUTO_INCREMENT.
я такой возможностью в таблице `messages` и не планировал пользоваться, поле с инкрементом всегда само устанавливается во вставляемой записи. Не пойму с чего вы это взяли?
garvey пишет:
ENGINE=InnoDB;
а чем ENGINE отличается от TYPE?
garvey пишет:
таблица всегда должна иметь уникальный первичный ключ. У вас его нет.
1075 Incorrect table definition; there can be only one auto column and it must be defined as a key
Когда я убираю AUTO_INCREMENT или убираю инкрементовое поле `no` или поле `time` из первичного ключа, то запрос проходит без ошибки и таблица создаётся.
Видимо INNODB почему-то не любит если в составе составного первичного ключа используется одно поле с AUTO_INCREMENT, а для меня этот инкремент нужен именно в таком качестве, потому что в одну секунду может поступить несколько сообщений, а уникальность каждого соблюсти надо. Я понимаю что можно обойтись одним инкрементным полем `no` в качестве первичного ключа, но хочется знать можно ли сделать именно по своей задумке? Зачем?
Ну, например, для того чтобы использовать поле `no` меньшего размера для экономии памяти, например TINYINT, если известно, что за 1 секунду не может поступить более 255 сообщений. Однако за всю историю существования чата сообщений может быть куда более 255, и разумеется нужно делать ключ для сообщений побольше чем в 1 байт(TINYINT), а время каждого сообщения в секундах от 1970 года тоже требуется хранить, и получается уже не совсем рационально.
Не могу на реальной практике испытать возможности механизма внешних ключей, не работает ни один из 3ех возможностей:
1. вывод ошибки при добавлении записи которая во внешнем ключе содержит значение, которого нет в поле другой таблицы, на которое ссылается он.
2. каскадное удаление.
3. каскадное обновление.
Вот мой пример:
INSERTINTO`messages`(`user_id`,`text`)VALUES(3,'Без связки!'),(1,'Со связкой'),(2,'И этот со связкой');
DELETEFROM`users`WHERE`id`=1;
UPDATE`users`SET`id`=4 WHERE`id`=2;
SELECT*FROM`messages`;
Он успешно проходит вместо того чтобы дать сообщение об ошибке при первой вставке, и выдаёт такую таблицу (справа я написал комментарий к строкам что меня не устраивает, и что я ожидал):
Цитата:
time no user_id text
6 1 3 Без связки! - Вывод об ошибке, т.к. нет пользователя с номером 3
6 2 1 Со связкой - это сообщения должно быть удалено с удалением пользователя с номером 1
6 3 2 И этот со связкой - у этого должен каскадно обновиться user_id и стать равным четырём
Главная
Помощь
Поиск
Пользователи
Найдено сообщений: 40
Прикольно, уже больше суток ни одного ответа, значит никто ROLLBACK для дела в связке PHP&MySQL не использует... т.е. никому не нужен, и заморачиваться в вопросе где его применять не стоит.
