Mandor

Нормально, но метод лучше пометить как static.

При условии, что у вас в любой момент времени суммарная скорость раздающих для любого контент,а который кто-то может захотеть забрать не меньше скорости забирающий этот контент, NAS будет не нужен. Однако даже в этом случае его работа не будет равна нулю, потому как если он будет что-то раздавать, значит это снизит нагрузку на кого-то другого и сэкономит ему электричество/канал.

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

Нормальная идея. Вообще, такие вещи нагрузку на сервер не создают. В реализации не используйте регулярки и ненужные циклы, обратите внимание на функцию strtr().

Можно ли JS использовать, чтобы заменять на смайлы? Или это непрактично?

Если отдаёте контент в виде HTML, то серверный вариант замены предпочтительнее.

Вы связали 1 и 3 способом "многие ко многим", это означает, что один и тот же столик может принадлежать нескольким ресторанам, не могу представить как такое может быть? В моём понимании каждый из ресторанов владеет своим набором столиков, в таком случае таблица 2 не нужна, а 1 и 3 должны быть связаны способом "один ко многим".

По поводу заказов: нужна одна табличка с заказами, в которой будет поле id_столика (BookId, TableId, SomeFields). Ваш вариант подошел бы для случая, когда заказ может быть сразу на несколько столиков.

Попробуйте "distinct user_id".

Кстати, cbr.ru умеет контент через SOAP отдавать.

Если задача позволяет - делайте несколько маленьких, так проще и удобнее. Другое дело, если вам нужна фильтрация/сортировки по полям join-нутых таблиц, тогда выбора нет.

500 кб - много, примерно 200 - нормально. И если показываете в уменьшенном виде, то должны быть тамбнейлы.

Вот пришло в голову: сделайте на сайт два алиаса: www.site.ru и www2.site.ru, ну и в случае если пользователь залогинен при повторном логине отправляйте на второй вариант (как вариант подойдет www.site.ru/1/ и www.site.ru/2/).

Сохранять ли в БД или еще куда зависит от того, как вы эти данные собираетесь использовать. Например, можно сохранять в MySQL, но делить таблицы по месяцам (новый месяц - новая таблица), если нужны старые данные - добавляете в запрос нужное количество UNION'ов.

Если у вас в проекте уже есть MySQL и нет Mongo, то лучше продолжать использовать MySQL.

Кстати существуют сторонние сервисы для менеджмента логов, может быть это выгоднее, чем поднимать инстансы монги?

А еще Excel умеет подгружать данные из XML-файлов. Причем форматирование и сами данные при этом находятся в разных местах, что может быть удобным. Экспортирование из PHP в XML неограниченной длины тривиально.

Поле "месяц" и поле "день месяца" в двух экземплярах. Если вам не важны високосные года, то просто количество дней от начала года.

Всю логику попадания в промежуток и пересечения промежутков можно встроить в SQL.

- Хранить PHP-код в базе не страшно. Но: 1. исполнять код из БД медленнее чем из файла (нужен как минимум коннект к БД + не очень быстрый eval, как максимум - еще и чтение таблицы с данными с диска), 2. редактировать код из БД обычно менее удобно, чем из файла (будь-то FTP-доступ или SSH), то же самое на счет отладки.
- Eval можете использовать, он для того и сделан, чтобы его использовали тогда, когда надо.
- Если хранить обработчики в файлах или даже добавить к ним и сами тесты никакого файлового ужаса не будет. Просто продумайте структуру заранее. Если вас пугает наличие 10000 файлов в одном каталоге - можно предусмотреть разбивку на подкаталоги, в каждом из которых будет например по 100 тестов. В конце концов как хранят фотки фотохостинги и видео - видеохостинги, не в БД же?!
- Про DSL идея хорошая. Помимо всего остального это поможет снять запрет на редактирование обработчиков тестов только разработчиком сайта.

если y == 0, то выдаем ошибку
z = x/y
если z >= 5, то ...
иначе если z >= 4, то ...
иначе если ...
иначе ...

Если вы недоумеваете почему не используется JPEG, то вот быстрый ответ на этот вопрос:



По сравнению с GIF, PNG такого же качества тоже весит меньше.