Это список участников.
Заходит участник, его логин записывается в файл (после проверки на дубль), выходит - удаляется. Все это делается самим скриптом. Из 1С можно только отправить "команду" по http вида
"http://aha.ru/1cvitter.php?action=login&login="+СокрЛП(Логин)
"http://aha.ru/1cvitter.php?action=exit&login="+СокрЛП(Логин)
которая и вызывает действия скрипта с файлом.
Я считаю, что в моем случае это не может вызвать никаких конфликтов кодировок.

это в математике

а в программирование - принято думать, ещё лучше - думать наперёд.

_____________
HTML, CSS (Bootstrap), JS(JQuery, ExtJS), PHP, MySQL, MSSql, Posgres, (TSql, BI OLAP, MDX), Mongo, Git, SVN, CodeIgnater, Symfony, Yii 2, JiRA, Redmine, Bitbucket, Composer, Rabbit MQ, Amazon (SQS, S3, Transcribe), Docker

Почему не СуБД, тот же SQLite? Зачем эти пляски с файлом?

Потому что никто не читает топик. Все только себя слышат.

Это - демоверсия, демонстрация технологии (не пхп, а в 1С), эскиз, пример, альфа-версия для тестирования, парадигма, образец, образчик, модель, первообраз, прообраз, прототип; сравнение, притча, иносказание, аллегория, метафора, метонимия, парабола, троп, фигура; иллюстрация, example; case; case study; exercise; illustration; model; pattern, Paradígma, exemple, esempio, ejemplo, modelo, ejercicio, örnek, үлгі, мысал. Не знаю как еще объяснить.
Минимум функционала (вход, выход, отправить сообщение), сделано за 2 часа, 200 строк кода в 1с и 100 в пхп. Никакой промышленной эксплуатации не предполагается. Если это будет работать. конечно сделаю на mySQL. Внешне- то ничего же не измениться. Со стороны 1С никаким способом нельзя понять каким образом это сделано.
В текстовом варианте я просто приколхозил кусочки готового кода к этой задаче и получил результат за 5 минут, а с пхп+СУБД пришлось бы повозиться - это же не в 1С-ине базу слепить пощелкав мышью в конструкторе. Вы действительно думаете, что я работаю с 1С и не знаю как правильно хранить и обрабатывать большие объемы информации для большого количества пользователей, а как не правильно?

Ничего не думаю. Просто спросил. Ну нет, так нет. =)

Мне показалось, что хранилищем (файлом) "пользуется" только PHP скрипт. Поэтому выбор в пользу SQLite был бы, с моей точки зрения, более оправданным. В силу его легкой миграции между платформами и достаточной производительностью даже в целях production.

Вы считаете иначе. Я спросил почему. Зачем так бурно реагировать? =)

ХренА себе! Столько эмоций на форуме давно не видел А надо заметить, что Павел абсолютно прав со своим вопросом насчет БД. Чем изобретать велосипед при хранении данных в файле, лучше сделать всё это в БД.

Судя по процитированному высказыванию - да, не знаешь как хранить большие объемы инфы. И малые объемы инфы тоже не знаешь. Потому что с ПХП+СУБД ты потратил бы те же 5 минут. Но без гимора - при условии, что ты с БД умеешь работать.

Да, я не вникал в этой теме, зачем ты это всё обрабатываешь. Смотрел только на то, как решить поставленный тобой вопрос. А Павел правильно заметил, что сама задача изначально некорректно поставлена, что тут лучше БД использовать.

_____________
* Хэлп по PHP
* Описалово по JavaScript
* Хэлп и СУБД для PostgreSQL

* Обучаю PHP, JS, вёрстке. Интерактивно и качественно. За разумные деньги.

* "накапливаю умение телепатии" (С) и "гуглю за ваш счет" (С)

Да ладно, шучу я так. ШуткаЮмора.
Да хранилищем (файлом) "пользуется" только PHP скрипт. Он пишет/читает 2 файла - один с он-лайн пользователями, второй просто как в стек кидает сообщения пользователей. И возвращает содержание первого файла (юзеров) и 150 последних сообщений из второго. 5 функций которые выполняет скрипт. Сколько может быть юзеров в он-лайне? 2-3, ну, пусть 10, пусть 100. Реально (если по логу смотреть) - 0 или 1. Ну в чем проблема если "хранилище" - суть текстовый файл из ста коротких строк?
Во втором файле - 300 строк. Это совершенно не критично для скорости. Дольше запрос и ответ будут по сети идти, чем скрипт отработает запрос и вернет результат.
На счет выбора СУБД я даже и не думаю об этом. Файл-хранилище чем хорош - ему ресурсов не требуется. Положил на любой сервер с поддержкой php и он с этого мгновенья заработал. Что еще нужно демоверсии? А чтобы использовать в связке с СУБД, я так понимаю, нужно денег дать, базу саму развернуть. И будет она называться так, как хостеру будет угодно. Впрочем, я не очень в теме, есть ли какая-нибудь принципиальная разница между всеми этими скулеобразными СУБД. Я так понимаю, скрипту php вообще параллельно нэйм СУБД на "том конце" май он или лайт ... Или я ошибаюсь? И выбор СУБД для связки с php принципиален?
Я ж одинесник. а одинеснику не надо задумываться над выбором "типа" хранилища или СУБД. Можно всю жизнь проодинесить и даже не знать: в дбфе ты сидел или в скуле. Это гипербола, конечно, но не такая уж и большая. Тебе надо думать о том как, в каком виде организовать данные, их обработку пользователем и вывод отчетов, а связи между таблицами, индексы, поля, запись, редактирование данных - это все делает сама система и вмешаться в это она не дает. В этом весь прикол, что о "технической" части заботиться не надо, чистое творчество ...

Хоспади, что такие впечатлительные-то все?! Это же просто копипаст словаря яндекса ... И уже пол-форума в панике ...
Почитали бы вы одинесные форумы. Впрочем, не стоит - это один шаг до психушки, поберегите психику и карму ...

Ну не все, положим, а только те, кто "копипастят словарь яндекса", не находя слов для выражения своей бури эмоций. А мы тут просто констатируем факт Не более того.

_____________
* Хэлп по PHP
* Описалово по JavaScript
* Хэлп и СУБД для PostgreSQL

* Обучаю PHP, JS, вёрстке. Интерактивно и качественно. За разумные деньги.

* "накапливаю умение телепатии" (С) и "гуглю за ваш счет" (С)