rPman

Если по каким то причинам не устраивает одна таблица (хотя, изучите такие вещи как кластеризация), то можно автоматически по структуре БД для каждой таблицы создать парную, заполняемую триггерами, при этом логику заполнения для разных таблиц можно варьировать — для одних хранить только факты добавления и удаления, для других добавить факты модификации, для третьих может понадобиться факты чтения данных (эти данные можно и не триггерами заполнять), где то можно вообще полный лог изменений данных (сохранять изменившиеся полей для истории изменений)…

Проблема потом интерпретировать эти данные… но, возможности, которые обеспечивает такой подход, очень велики.

из самого простого, особенно если с правами мало заморочек, любой вики-проект и общие договоренности о стилях наполнения

первые же результаты из гугла: Викизнание: Каталог wiki-движков и Вики-движок

это феерично! что именно вы хотите в таком случае от фреймворка?
* первая страничка — зависит от выбора серверной части, но в конечном счете без фреймворков это 5-6 строчек кода!
* вторая страничка — картинка меняющая прозрачность? это в css делается, какие фреймворки? доступ к железу изменяющему яркость света? опять таки от него зависит, но по любому еще 5 строчек кода.

это что за windows way?
'положить необходимые библиотеки' это и есть 'установка', какие проблемы? на удаленном компьютере в репозитарии нет необходимой версии? найдите или соберите свою сборку под версию ту OS и передайте вместе со своей программой, если с той стороны боятся что ваша сборка что то порушит — пусть устанавливают библиотеки и программу в chroot копию самих же себя, скрипты этого дела из пары команд можете сами написать (sudo cp -rx / /chroot;sudo chroot /chroot;… хотя не, создание копии системы еще тот вопрос, лучше вместо cp -xr прописать список каталогов, гарантированно принадлежащих системе), но то, мне кажется, извращение

p.s. если на удаленном компьютер не установлены драйвера, то ничего не получится… ставить их придется без вариантов.

p.p.s. спросите их про тип видеокарты на той стороне и подготовьте свой демонстрационный дистрибутив в виде iso файлика (благо с поддержкой opencl это либо ati, либо nvidia, либо изредка intel), а уж прожечь компакт диск и запустить его сможет практически любой пользователь.

Хранить в базе смещение (можно поделить на размер сектора или больше 4096...) и размер файла, при должном красноглазии можно завернуть оба числа в 64bit long и пользоваться им как идентификатор файла, сами файлы хранить в одном большом контейнере (можно не сильно заморачиваться с файловыми системами и складывать прямо в /dev/sda), как результат — максимально быстрый доступ к файлам (быстрее — только при самостоятельной организации кеширования под задачу) и максимально неудобное обслуживание при частых удалениях/изменениях файлов (запись только в конец контейнера, по окончании места — полная реорганизация хранилища, с выдачей новых id… но это может оказаться приемлемой платой и в некоторых задачах ее даже не придется платить).

p.s. посчитали это шуткой? просто все зависит от задачи и особенностей использования данных.
Вышеописанный способ использовался достаточно давно для не web-проекта, обеспечивал 'максимальную из возможных' производительность при резервном копировании, чтении и добавлении новых файлов, позволял организовать версионность 'из каропки',…

Залил приложение на appspot.com (настройки базы High Replication), Test.amount увеличивается успешно, но проскакивает такое:

# curl blablabla.appspot.com/test
Test length:1
Test[1]: 9
Test repeat read: 10, queryed:9

# curl blablabla.appspot.com/test
Test length:1
Test[1]: 10
Test repeat read: 11, queryed:10

# curl blablabla.appspot.com/test
Test length:1
Test[1]: 11
Test repeat read: 12, queryed:12

# curl blablabla.appspot.com/test
Test length:1
Test[1]: 12
Test repeat read: 13, queryed:12

# curl blablabla.appspot.com/test
Test length:1
Test[1]: 13
Test repeat read: 14, queryed:13

Т.е. нет никакой гарантии что Query вернет верные данные, но каким то образом данные все равно корректно изменяются.

p.s. уже размышляю по исключению из проекта любых Query и работа с данными исключительно по id (а особые списки реализовывать самостоятельно) все еще надеюсь что я где то ошибся, ибо это нереально глупое поведение БД

Стало еще страшнее!!! я ошибся выше в коментарии, не перепроверил, если запросить после изменений данных данные объекта через Query execute() и .get(0) то данные ВООБЩЕ никогда не записываются!
Добавив код после обновления данных:

q=pm.newQuery(Test.class);
qdr=(List)q.execute();
q.closeAll();
resp.getWriter().println(«Test repeat read: „+d.getAmount()+“, queryed:»+qdr.get(0).getAmount());

т.е. вывод всегда такой:

# curl 127.0.0.1:8888/test
Test length:1
Test[1]: 44
Test repeat read: 45, queryed:44

# curl 127.0.0.1:8888/test
Test length:1
Test[1]: 44
Test repeat read: 45, queryed:44

# curl 127.0.0.1:8888/test
Test length:1
Test[1]: 44
Test repeat read: 45, queryed:44

для очистки совести проверил, конечно ничего не изменилось, там d=pm.getObjectById(Test.class, new_id); исключительно для тестов и вывода в лог данных далее по коду.

Гарантированно сериями по 2 запроса данные тупо никуда не записываются, при этом в пределах метода сервлета данные успешно записаны, доступны по повторным запросам через Query, но по завершению метода и выдачи результата клиенту изменения куда то исчезают

p.s. в основном проекте все еще хуже… в один объект данные сохраняются, в другом, записываемым в этом же методе — нет, группы у объектов разные, в транзакцию завернуть еще не могу, я пока еще не придумал красиво объединить в группу слабо связанные сущности, по документации, чтобы это сделать — нужна связь типа 1к1 или 1кМ, либо что то нетривиальное с ключами

pm.flush() в finally ничего не изменил.

доступ к онлайн-пузомеркам (размещение достижений оплатившего доступ в соотв. рейтинговых табличках на сайте разработчика)

Почти наверняка проблемы с вебсервером или может быть DNS?

gentoo, apache, тормозной старенький AMD Sempron(tm) Processor 3400+

a.php: <?php echo str_repeat('0123456789012345',8192); ?>

# date; curl http://localhost/a.php >/dev/null;date
Втр Авг 9 20:15:03 NOVST 2011
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 128k 0 128k 0 0 31.4M 0 --:--:-- --:--:-- --:--:-- 41.6M
Втр Авг 9 20:15:03 NOVST 2011


p.s. но если у вас тоже самое с cli php то нужно бить тревогу!!!

p.p.s. у меня на first vds был момент, когда простейший lib_curl (точнее вызовы curl_… из php) нещадно подвешивали виртуалку под 100% на секунды, но в то же время консольная утилита curl/wget — работали без проблем… пока вообще выяснял, откуда тормоза, проблема самоустранилась (длилась часами), поэтому записал на счет потенциальных глюков openvz (точнее virtuozzo) и сделал зарубку в памяти, что и такое возможно.

как я понимаю во второй строке ошибка, не '\$a' а '&$a'?

$a = 'a'; // переменная a значение a
$b = &$a; // переменная b значение всегда будет равно значению переменной a (т.е. сейчас это 'a')
$c = $$b; // переменная c равна значению переменной, имя которой в переменной b, т.е. равна значению переменной a, значит равна 'a'
$a = 'bb'; // переменная a меняет значение на 'bb', значит переменная b так же теперь возвращает 'bb'
print "$$c\n"; // выводит значение переменной, имя которой в переменной c, сейчас там значение a, значит результат переменной с именем a сейчас 'bb'
print "$c\n"; // значение переменной c — 'a'

Не нужно ЗАПРЕЩАТЬ! сначала предоставьте народу разумную альтернативу!

Как я понимаю ваш сервер (если его нет, лучше поставьте любую фигню, хоть на mini-itx от 1.2р плата + память + БП + корпус хоть из картона)?
Установите на сервер торрент клиент и дайте народу доступ к его вебморде! вроде есть к rtorrent такие, что даже многопользовательский доступ с ограничениями предоставляет, в крайнем случае это меньшее из зол, если все будут видеть и рулить общим списком торрентов.

freenet + frost = распределенная децентрализованная сеть хранения данных (сайты, форумы, блоги — статика) + мессадженер вида nntp/email на ее основе. Заточено на секурность и анонимность (уровня выше tor и анонимные прокси).

Немного тормозной, в начале пару гигов выкачает и 512мб на диске под базу выжрет (минимум), java (кросплатформенно), немного устаревший интерфейс но юзабельно и со своими задачами справляется.

Если требуется решить вопрос о законности, а так же высокие требования к скорости (вайфай, мало того, ненадежен, достаточно соседям точку доступа поставить, так еще на таких не очень больших расстояниях, в лучшем случае получите десятки мегабит), то…

… прямая видимость может позволить использовать атмосферные оптические линии связи, т.е. передача данных по лучу — потенциально выше скорость, и расширяемо (при построении 'сотовых' сетей или использовании репитеров), т.е. каждый канал не мешает другому.

p.s. на хабре даже был обзор таких устройств с примерами (сотни метров и мегабитов, вполне подъемные цены, даже малому бизнесу, особенно если 'китайцы' будут стараться, а не отечественный 'наклейкопром'), только не могу найти.

PHP не очень пригоден (точнее не предполагает подобного использования, но формально ничто этому не мешает) для использования как постоянно запущенной службы, вместо режима частых и коротких запусков

Соответственно, можно использовать асинхронные сокеты (см. socket_set_nonblock и socket_set_option, первый же пример в гугле) в php и серверную часть запускать в виде одного процесса (со всеми вытекающими проблемами из-за потенциальных багов в коде, точнее прервутся все соединения, если упадет это приложение), либо на каждое соединение запускать по процессу, с обычными сокетами, но тогда добро пожаловать в мир semaphore и shared memory (конечно, можно и без них, используя типичный LAMP подход, когда за синхронизацию отвечает БД с транзакциями, но производительность будет ужасная и вас засмеют за говнокод).

p.s. Сильно не копал, возможно есть куча готовых фреймворков или даже расширений PHP, добавляющих событийный функционал.

Как обычно два пути — если есть деньги, то покупаем готовое решение (тут уже вариантов накидали), а если есть прямые руки и желание сэкономить за счет времени то собираем по частям.

Благодаря наличию очень дешевых комплектующих, электронную начинку не будет проблемы собрать (mini-itx или даже mATX), но вот корпус и, возможно, блок питания могут быть проблемой (особенно если жестких дисков будет много), именно тут необходимо проявить смекалку и умение 'работать паяльником' (вообще то нужны умения работы по железу и пластику/дереву для коробки, плюс грамотно спроектировать размещение и размеры для охлаждения и звукоизоляции).

p.s. естественно, такая возня требуется, если цель — уменьшить размеры и шум сервера, иначе лучше приобрести готовый крупный корпус и собрать 'обычный' компьютер.

первая задача решается элементарно :)
1. выбираем одного ведущего (не обязательно среди студентов)
2. Ведущий загадывает случайное число в уме (достаточно большое, сравнимое со обычным средним баллом * N) и говорит его первому студенту 'на ушко'
3. Каждый последующий студент прибавляет к этому числу свой балл и сообщает результат другому
…
4. по окончании последний студент так же шопотом говорит свою сумму ведущему
5. ведущий вычитает свое число из результата и делит его на N

т.е. никто не видит всей картины, а значит никаких вычислений провести не сможет (даже если кто то услышит случайно чью-то сумму, это ничего не даст).

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

Я бы не рекомендовал удалять данные из сложных баз данных, особенно если это справочники, например выставив в freign key — RESTRICT, чтобы разрешить удаление только для 'свободных' записей. Удаление записей в сложных базах данных, обычно очень сложная операция, обычно перед этим приходится проводить кучу проверок и изменений для связанных данных, поэтому флаг 'deleted' используется как упрощение или даже часть механизма для введения временной составляющей в хранение данных (база данных может являться как средством для хранения текущего состояния, так и для хранения лога изменений данных во времени)

В зависимости от задач:
1. Если удаление происходит сравнительно редко, т.е. если оверхед на размер базы незначителен — то лучше помечать флагом.
2. Если удаления и создания записей очень частые (в результате база не очень растет), то лучше удалять, плюсы от отсутствия фрагментации может оказаться недостаточным, чтобы перебить рост индексов (кстати и кэш в оперативной памяти будет зря занят).
3. Если и скорость и данные критичны, то лучше помечать флагом и удалять по крону, а чтобы минимизировать вероятность задержек на время обслуживания — разделить таблицу на кластеры (можно 'вручную' в классе работы с БД) и очищать каждый кусок отдельно, а разделение сделать с целью отделить часто используемые данные от редко используемых.