Александр

Вопрос поставлен не совсем корректно, т.к. может быть 2 трактовки:

1. Если речь идет о веб-скриптах, которые выполняются последовательно, то чем вам не нравится сессия? В данном случае это не костыль — она именно для этого и придумана. Если не нравится непосредственно стандартная реализация, то можно взять собственную (принципиально аналогичную): генерировать ID клиента (сессии) и передавать его через get/post/cookie (по вкусу), а уже сами данные хранить либо в файлах, либо в базе данных, и получать с помощью этого идентификатора в качестве ассоциативного ключа.

Непосредственно данные через куки, гет и пост передавать естественно в данном случае не стоит: эти вещи всегда можно подделать, т.к. они идут через клиента. Это можно назвать костылем :)

================
2. Если же речь идет о выполняющихся одновременно 2 шелл-скриптах, т.е. межпроцессное взаимодействие (IPC), то тут можно использовать разные более или менее системно-зависимых вариантов. От стандартных механизмов IPC: семафоры, сообщения, шаред блок памяти, до специфичных вещей вроде именованного пайпа или сокета; или же аналогичных п.1 вещей (база данных/файлы).

> Также может посоветуете какую-нибудь opensource баннерную систему на PHP?
OpenX попробуйте. Очень «тяжелая», но весьма функциональная.

Скорее всего там структура базы включает эту возможность: при сохранении данные не апдейтом заменяются в базе, а добавляется новая строка.

Простейшая структура с минимальным кол-вом необходимых полей выглядит так:
— article_id (не уникальный)
— timestamp
— content

Соответственно при сохранении добавляем новую строку с тем же ID, но более свежим таймстампом. При выборке — берем наиболее свежий (запросы с группировкой, либо дополнительное обновляемое поле с флажком для пефоманса).

Действительно, понятия немного из серии «что лучше, Алла Пугачева, или цветной телевизор». Однако если я правильно понял мысль автора, постараюсь ответить :)

Все очень зависит от используемого языка. Но в целом сразу видятся такие причины:

1. Глобальную переменную может случайно переопределить другой модуль. Получим сложно отлавливаемую ошибку. Класс же, посредством которого реализован паттерн синглтон в большинстве языков переопределить нельзя. Ну или по крайней мере можно получить ошибку компиляции (в компилируемых языках).

2. Область видимости имен классов обычно не зависит от контекста. Глобальная же область переменных в некоторых языках опять же может меняться.