@demimurych честно сказать, даже и не знаю... Если рассуждать чисто логически, то чем меньше записей, тем быстрее все это дело будет работать. Возможно в данном случае это не так? Не знаю. Я в MySQL не большой специалист. Если кто просветит по этому поводу, буду только рад!
@gwer "на мой взгляд, такое решение удобнее, чем каждый раз проверять, появилась, существует ли уже 30 записей" - тогда придется проверять первая ли это игра
@gwer
1. Тогда будет не удобно делать выборку, т.к. придется фильтровать, показывая только 30 последних значений и самое первое. А если делать как я объяснял, то просто делаешь селект с условием по user_id и game_id (по ним есть индекс). Результатов будет всегда <= 30 + самый первый результат.
2. Вы забыли о том, что необходимо хранить (не удалять) самую первую запись (чтобы можно было видеть свой прогресс).
@svd71 нет, как раз выполняться он будет довольно часто. При каждом сохранении нового результата. Т.е. при сохранении результата:
1. нашим запросом удаляем "лишние" записи (поскольку мы будем делать это при каждом сохранении, то "лишней" будет всегда одна запись)
2. добавляем новую запись
В итоге получаем, что каждый пользователь для конкретной игры может сохранить 30 последних результатов + самый первый
Запрос, кстати сказать, для моих условий не совсем верный (т.к. в условии удаления учитываются пользователи, но не учитываются игры), но суть мне понятна. Спасибо!
Если есть мысли как эту задачу выполнить более правильно, то буду очень рад, если Вы ими поделитесь.
@svd71 спасибо большое! Но запрос с двумя подзапросами... если учесть, что в таблице будет минимум 30 млн. записей, то насколько это будет быстро работать?
@Mandor спасибо, про eval я думаю так же как и Вы. Что касается хранения кода в базе, то я считаю, что в 99.9% случаев это не требуется, но как и во всех правилах в этом тоже бывают исключения. Свой случай считаю как раз таким исключением, поскольку это сильно упрощает дело. Ведь при использовании файлов придется позаботиться о динамическом создании директорий, количестве файлов в каждой директории и т.п. вещи. С базой проще, INSERT и все дела. Кроме того все будет в одном месте, я имею ввиду что тест это одна строчка в базе.
По поводу редактирования кода, то это в любом случае будет онлайн редактор, поэтому откуда загружается код совершенно не важно.
В общем решил поступить так. Сделаю хранение php-обработчиков в базе. Обкатаю это решение в течении пары месяцев. Посмотрю на производительность, удобство и прочее. Если все нормально оставлю как есть, если будут проблемы перейду на хранение обработчиков в файлах (переделать не сложно).
@storoj "В базе ничего не отрефакторить, не выделить общего" - про выделить общее не понял, а рефакторить можно. Разницы нет куда/откуда Вы загружаете/сохраняете.
"Нет контроля версий. Хуже развертывается" - что там развертывать? Там максимум что будет (в моем конкретном случае) набор инструкций if...else
@FrimInc именно о таких "макросах" и идет речь, ничего более сложного не требуется. А как такое условие упаковать и чем потом распаковать и как пользоваться?
@Sander_Li да напишите, а то может я просто не в теме. И еще пожалуйста если не трудно напишите какой системой контроля версий пользуетесь Вы и почему?
@storoj поймите, что почти каждый тест (если не считать тех, что выдают результат по сумме баллов) требует своей логики обработки. И что мне при добавлении нового теста каждый раз метод в класс дописывать? Очень скоро этот класс будет несколько десятков МБ весить. Да и не удобно это.
Отбрасывать мысли о том, что уведут не стоит. Поскольку уведут однозначно, и, причем, очень быстро. Не вижу смысла долбаться над этим разделом сайта, если через неделю мои тесты (часть из которых авторские) будут на десятках сайтов.
@Sander_Li да хоть тот же бэкап. Каждый день бэкапить 10000 файлов (и это только раздел тесты) или 1 БД. Или переезд на другой сервер. Что проще перенести 10000 файлов или 1 БД?
И, вообще, мне кажется, что плодить файлы на винте не лучшее решение. У меня по cron-ну скрипт бегает по файловой системе и сохраняет хеши файлов. При повторном забеге он сравнивает текущий хеш с запомненным ранее. Если не совпадают, то файл модифицирован. В общем защита такая. И соответственно чем больше файлов в системе тем дольше он работает и создает бОльшую нагрузку. Для меня это важно.