первые значения из нескольких строк с их номерами???????????????
Стандартных - не припомню... Читайте файл в цикле, одновременно отсчитывая строки, сверяйте с нужным значением, если совпадает - сохраняйте куда-нибудь, например в массив.
@функция - скрыть вывод ошибки, если произойдёт
#, так же как и /* */, // - комментарии.
! булевое отрицание
_ - просто символ
. - конкатенация (объединение) 2-х строк
$_ - не глобальный массив. Просто переменная, начинающаяся с нижнего подчёркивания. Вам ничто не мешает объявить строки $_get и при этом она будет обычной переменной. (следите за регистром букв по этому, php к нему чувствителен)
Если грамотно работать с сессиями то действия направленные на отправку сообщения от другого лица будут весьма затратными по времени и потеряют всякий смысл
Hunter пишет:
вот например этот форум узнает меня даже после перезагрузки компа))))))))
Ну а меня узнает под 2-я разными системами, и авторизоваться просит где-то раз в месяц и что?
Вот вы сможете доказать, что вы - это тот же человек, что писал предыдущее сообщение с этого аккаунта, а не кто-либо перехватил идентификатор?
Ну это теория, просто при желании перехватить можно всё. Можно лишь изобретать способы этого усложнить.
Hunter пишет:
сперва формируется php скриптом гна сервере исходя из данных полученных при авторизации юзера и параметров добавленных из БД для этих данных. Слишком муторно делать то о чем ты написал.
Не, не слишком. wget'ом получаем страницу, редактируем JS, открываем в браузере. Сервер не знает о лишних действиях, но JS уже отдаёт подставные данные.
По авторизации:
Я бы, наверное, выдавал JS только сгенерированный идентификатор, допустим с помощью MD5 от ида пользователя и текущей даты и дописывал бы в таблицу пользователей, и при отсылки нового сообщения, проверял, если авторизован пользователь с таким идентификатором - то добавить сообщение.
зависит ли от количества таблиц что то еще кроме удобности использования(для меня лично) ??
Объём базы и количество запросов, собственно, никак не связаны.
Наибольшую задержку даёт подключение к СУБД, пересылка запросов-ответов, разбор запроса на стороне СУБД. Непосредственно выборка данных происходит очень быстро.
Скорость выполнения запроса зависит от количества задействованных в запросе таблиц, а в остальном - таблицы в базе данных никак физически не связаны (только логически, что и надо реализовывать в запросах) и друг на друга потому не влияют.
Вообще, по теории реляционных баз данных - все таблицы с повторяющимися данными (в пределах одного поля, в частности) надо делить на несколько таблиц, т.е. большое количество таблиц приветствуется. Но выборка и предшествующее ей связывание таблиц работает тем медленнее, чем больше участвует таблиц. Так что оптимум где-то посередине...
Hunter пишет:
можно ли "построить" профиль один раз при загрузке страницы и возложить его (профиля) хранение на плечи JS дабы не обращаться многократно за какими то характеристиками юзера
А что у юзера за характеристики в чате? К которым надо многократно обращаться?
Ch_chov пишет:
Следовательно пользователь сможет сам выставлять эти параметры, например, для того, чтобы отправлять сообщения от чужого имени...
Пользователь так или иначе сможет это сделать в любом случае, т.к. со 100% уверенностью сказать, что сейчас к серверу обратился тот же человек, что и 5 секунд назад - невозможно.
Каждый запрос и функция по определению снижают скорость отдачи страниц. Так что стремиться надо всегда к 0.
"не считается вредным" - не совсем корректный вопрос, не вредным будет чем меньше, тем лучше для одного и того же эффекта.