В первую очередь, не пытайтесь использовать технологию для нанесения поражения технологии.
Ваши проблемы:
Ваши Цели:
Цель № 1: Поддерживайте сайт в рабочем состоянии на скорости, которую не замедляют боты.
Это на самом деле довольно просто. Сделайте, чтобы кто-то еще разместил страницу. Вместо первой полосы, размещаемой на Ваших серверах, имейте Amazon S3 / Akamai размещают страницу. Большая часть страницы 'статична' во всяком случае. Повторно создавайте страницу каждые 5 минут или таким образом, более динамические объекты обновляются. (Черт, повторно создайте его каждая 1 минута, если Вы хотите). Но теперь боты не поражают Ваш сервер - они поражают CDN Akamai, который может, конечно, взять загрузку.
, Конечно, делают это для каналов RSS также. Нет никакой причины, почему некоторый другой сервис не может взять пропускную способность / хит загрузки для Вас. На связанной ноте все изображения служили Akamai, и т.д. Почему получают удар?
Цель № 2: Продайте товар к несценариям людей
, я в согласии с другими который, поскольку, которые говорят, делают его так, чтобы сценарии не давали реального преимущества. Однако сценарии являются также знаком влюбленного woot клиента, таким образом, Вы не хотите быть a*hole также.
, Таким образом, как я сказал бы, позволяют им купить, но заставить их заплатить расширенную сумму (или более предпочтительно) просто, замедляют их так, чтобы у других был шанс.
Так каждый раз, когда пользователь совершает нападки, сайт предлагают мешок дерьма на уровне 29,99$ и имеют таймер на случайной скорости, отбрасывают или повышают цену. Имейте изображение или некоторый другой индикатор, который говорит людям, если цена понизится, если они будут терпеливы.
у пользователя есть кнопка "Buy now!", которую они нажимают, когда они видят, что price/# объекты тем, что они хотят.
Пример:
Пользователь:
повторение....
на постепенно напрягающемся цикле, который удлинит время корректные "4,99$ (пробует itemos)" отображен
, Если хиты бота обновляют затем перезапуски цикла. Если пользователь, пропускает и выбирает несправедливость # объектов / цена - решает, хотите ли Вы позволить им купить по той цене.
, Если они "сорят деньгами", например, они платят 24,99$ за 3 объекта, и woot только собирался заряжать их, 4,99$ для 3 объектов затем включают купон за 20$ от их следующей покупки woot.
Цель № 3: не изводите 'нормальных' пользователей ни с какими задачами завершиться, чтобы доказать, что они являются человеческими.
Вы делаете логическую ошибку здесь. Вы предполагаете, что любой Тест Тьюринга ( http://en.wikipedia.org/wiki/Turing_test) должен быть раздражающим. Это не верно!
Вот некоторые идеи:
Только спрашивают 3 раза, так как все, что Вы действительно хотите сделать, замедляют сценарий kidees.
Думаю, все в порядке. Вы описываете связь «один ко многим» между продуктом и текстом его локализации.
Мне интересно, следует ли вам также локализовать английский язык вместо того, чтобы денормализовать его в таблице продуктов.
Я считаю, что правильным способом было бы создать дополнительную таблицу, но затем перейти к дополнительному шагу и удалить все ресурсы для конкретного языка из первой таблицы.
Итак, у вас будет:
продукт
id
-name removed
-description removed
локализация продукта
productid, locale_id, name, description
------------------------------------------------------
1, 3, pomme, un fruit délicieux
1, 4, apfel, ein köstliches Obst
1, 1, apple, a delicious fruit
локаль
id, locale
--------------
1, en
3, fr
4, de
Если я правильно понимаю, ваша проблема только в том, что вы хотите использовать одну и ту же языковую локализацию для имени и описания в более чем одной таблице. В таком случае вы не можете добавить prod_id в таблицу локализации. Еще одна проблема в вашем дизайне заключается в том, что он не может элегантно обрабатывать более одного языка локализации для одного и того же продукта. Вы можете настроить его для работы:
Если имя и описание - единственные поля, требующие локализации, вы можете сделать следующее.
Продукт (ID, имя, описание, tanslation_row_id)
Product_translations (ID, name, description, lang_id, translation_id)
translation_row_id будет внешним ключом, указывающим на Product_translations.ID Однако translation_id будет указывать на родительскую запись в той же таблице, которая будет служить общей записью для всех языковых записей.
Примеры записей
Продукт
(ID, name, description, translation_row_id)
(p1, apples,a red fruit, tr1)
(p2, mango, a yellow fruit, tr2)
Product_translations
(ID, name, description, lang_id, translation_id)
(tr1, apples, a red fruit, ENU, null)
(tr2, mango, a yellow fruit, null)
(tr3, pomme,un fruit rouge, FRA,tr1)
(tr4, mangue,a yellow fruit, SPA,tr2)
Учитывая код языка, вы можете извлечь значения имени и описания с помощью следующего SQL-запроса
select T.name, T.description
from product_translations T
where T.translation_id =
(select T2.ID
from Product P,Product_translations T2
where P.translation_row_id = t2.ID
)
and T.lang_id = '&langID';
Важное примечание: я предполагаю, что в таблице продуктов гораздо больше атрибуты, которые не нуждаются в этом переводе. '& langID' - параметр для запроса SQL, который запрашивает у пользователя код языка по его выбору
Мне нравится эта идея, но я бы сделал шаг в другом направлении, и завел бы запись локализации для каждой колонки, которая переводится:
страна
id, localization_id
-----------------------
1, 5
продукт
id, name_locale_id, description_locale_id
----------------------------------------------
1, 2, 8
локализация
id, locale_id, value
------------------------------------------------------
2, 2 apple
2, 3 pomme
2, 4 apfel
5, 2 ireland
5, 3 irlande
8, 2 a delicious fruit
8, 3 un fruit délicieux
8, 4 ein köstliches Obst
9, 2 a small country
9, 3 un petite pay
локаль
id, locale
--------------
2, en
3, fr
4, de
PK локализации - это (id, locale_id). Не проблема, что id также является FK ссылкой в нескольких других таблицах. Вы можете добавить суррогатный PK, если хотите, при условии, что у вас все еще есть уникальный индекс на (id, locale_id).
Хорошая вещь в этом - это одна таблица локализации, и она работает для любой таблицы в вашей схеме, независимо от того, какие поля она имеет (вы не ограничены наличием имени и описания всего, что локализуется). Недостатком является потенциальное снижение производительности при использовании таблицы локализации - хотя потенциально вы можете просто кэшировать всю информацию для данного locale_id, так что при поиске записей вам нужно будет искать только данный id (поскольку ваш кэш уже основан на языке).
Вы также можете рассмотреть возможность оставить в таблице продуктов поля названия и описания по умолчанию, которые будут использоваться в случае, если запись отсутствует для текущего языка, или при вводе пользователь не указал язык. Это также будет актуально, если вы переносите существующее приложение, там уже есть значения (без информации о локали).