$_SERVER['REMOTE_ADDR'] - это строка, "1.1.1.1/24" - тоже строка. Строки сравниваются посимвольно.
Вам нужно разбить строку на 4 числа (+ число маски подсети), эти 4 числа преобразовать в 32-битную последовательность и проверить на равенство первые, в вашем случае, 24 бита. И вот если они равны - можно перенаправлять.
Не вижу здесь несовершенства протокола. И не понятна цель, которую вы преследуете. Если вы хотите повысить, скажем так, доступность контента, то дополнительный сидер в виде NAS вам конечно поможет, особенно в ситуациях, когда сидеры все уйдут и останетесь только вы.
По первому варианту я уже высказался - связь многие-ко-многим не нужна. Есть таблица ресторанов с дополнительной информацией, есть таблица столиков, у каждого из них указан id ресторана (один-ко-многим), есть таблица мест за столиками у каждого из которых указан id столика. В таблице заказов у каждого заказа указывайте id столика, либо id места, либо еще одну связанную табличку (один-ко-многим) с местами для каждого заказа (для оптимизации эту табличку можно упаковывать в поля таблицы заказов типа поле id_мест и содержимое, например "1,10,15".
По второму рисунку. Place и Table - все нормально. OrderAndTable нужно только, если у вас в одном заказе бывают несколько столиков.
"в первом ресторане 30 столиков а с id от 1 до 30, а во втором Id будут уже от 30 до 60 к примеру" - никаких проблем и даже если у вас будут вперемешку id столиков разных ресторанов.
"Можно ли как то сделать составной ID типа у одних столиков от 1 до 30 но с PlaceId 1, типа 1_1, 1_2 и тд?" - можно сделать первичный ключ по двум полям сразу, причем второе будет auto_ancrement - нормальное решение, просто с некоторыми ORM'ами можете испытывать некоторые неудобства.
Когда вы залогинены на компьютере находится некоторая информация, позволяющая получить доступ к сайту минуя процедуру ввода логина и пароля. С точки зрения разработчика сайта должен быть способ удалить эту информацию.
На бэкэнде воркерный сервер построенный по принципу nginx'а, т.е. висячие коннекты дешевы. С другой стороны я понимаю, что коннект на локалхост тоже дешев (пока да, на локалхост). Итого, опять не понятно что предпочтительнее. Спасибо за интересный ответ.
@voff Я не понимаю что я должен проверять. Я не подвергал сомнению результат вашей выборки (тем более результат вы и не написали), а только то, что сам по себе запрос ужасен.
O(n) конечно же не будет. В моем случае надо 2 раза (т.к. 2 запроса) произвести по n сравнений (выборка по ключу + не используя индексы, т.к. иначе там бинарные деревья). В вашем случае делается декартово произведение, следовательно x*y сравнений.
@voff
1. Я не про дублирование информации в разных таблицах, я про дублирование при получении ответа на запрос.
2. В этом вовсе не "нет ничего страшного", в зависимости от содержания БД такой запрос может начать перегонять с сервера БД к приложению да хоть 99% данных, которые будут немедленно удалены (потому что одна строчка будет повторена много раз).
3. То что вы предложили не просто не является оптимальным, а именно противопоказано. Оптимизация, которую вы предложили (а это именно оптимизация - как из двух "железобетонных" запросов к БД сделать один), ну просто ГОРАЗДО хуже простого-тупого способа сделать в лоб двумя запросами.
4. Не понимаю при чем тут сложность алгоритмов. Очевидно что в случае двух запросов она не больше (а скорее всего меньше), чем в случае JOIN запроса. Что-то типа O(n^2) против O(n*2)
@voff Я уже писал выше, что при таком банальном джоине получим дублирование информации в записях на стене. Например, 1 запись на стене, у нее 10000 комментариев, при таком джоине получаем 10000 записей на стене. Получение 9999 лишних дубликатов не нужно и не может быть оправдано любовью любыми средствами сделать из двух запросов один.
@voff Я не знаю что будет со временем, я даю совет основываясь на текущем моем опыте. Джоины здесь по нормальному не применить. Есть вариант "для извращенцев": LEFT JOIN + GROUP BY + GROUP_CONCAT(), но лучше дополнительным запросом.
Джоины тут использовать не оптимально, т.к. они будут дублировать данные из таблицы с записями (т.е. одна запись будет выдана вам столько раз, со скольки комментариями она сджойнится). Самое простое тут просто делать второй запрос на каждую запись. В дальнейшем можете оптимизировать так, чтобы забирать комментарии сразу для нескольких записей (при помощи wall_id IN ... либо wall_id = 1 or wall_id = 2 ...).
Спасибо за подробный ответ. Все таки, какой вариант выбрать: реализация SNMP-протокола в своем приложении или реализовать CLI/HTTP/MySQL/Redis (отдача статистики в виде XML через HTTP уже реализована) интерфейс и просто заббикс настроить на понимание этого?
Написано
Войдите на сайт
Чтобы задать вопрос и получить на него квалифицированный ответ.
Вам нужно разбить строку на 4 числа (+ число маски подсети), эти 4 числа преобразовать в 32-битную последовательность и проверить на равенство первые, в вашем случае, 24 бита. И вот если они равны - можно перенаправлять.