2009-02-05 4 views
4

У меня есть небольшой проект, который я делаю на Python, используя web.py. Это генератор имен, используя 4 "части" имени (firstname, middlename, anothername, surname). Каждая часть имени представляет собой коллекцию entites в базе данных MySQL (name_part (id, part, type_id) и name_part_type (id, description)). Базовый материал, я думаю.Случайная стратегия генератора имен - помогите мне улучшить его

Мой генератор выбирает случайную запись каждого «типа» и собирает комическое имя. Прямо сейчас, я использую select * from name_part where type_id=[something] order by rand() limit 1, чтобы выбрать случайную запись каждого типа (поэтому у меня также есть 4 запроса, которые запускаются на просмотр страницы, я полагал, что это лучше, чем один жирный запрос, возвращающий потенциально сотни строк, если у вас есть предложение о том, как вытащите это в одном запросе w/oa sproc, который я буду слушать).

Очевидно, что я хочу сделать это более случайным. На самом деле, я хочу дать ему лучшее освещение, не обязательно случайность. Я хочу убедиться, что он использует как можно больше возможностей. Вот что я задаю в этом вопросе: Какие виды стратегий я могу использовать, чтобы дать покрытие по большому случайному образцу?

Моя идея состоит в том, чтобы внедрить столбец счетчика по каждому name_part и увеличивать его каждый раз, когда я его использую. Мне понадобилась бы некоторая логика, чтобы потом сказать: «Получите имя_частие, которое меньше, чем самый высокий« счетчик »для этого« name_part_type », если нет никого, тогда выберите случайный». Я не очень хорошо разбираюсь в SQL, возможна ли такая логика? Единственный способ, которым я могу это сделать, потребует до 3 или 4 запросов для каждой части имени (так что до 12 запросов на просмотр страницы).

Могу ли я получить информацию о моей логике здесь? Я переусердствовал? Это действительно идеально подходит для хранимой процедуры ... но можете ли вы, ребята, хотя бы помочь мне решить, как это сделать без sproc? (Я не знаю, могу ли я использовать sproc со встроенным файлом базы данных web.py).

Надеюсь, это не очень глупо, но спасибо заранее.

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

ответ

4

Я думаю, что вы после:

select * from name_part 
    where type_id=[something] 
    order by used_count asc, rand() 
    limit 1 

Это поместит меньшие используемые имена в верхней части списка, и, если кратный есть с таким же (самым низким) used_count, они будут сортировать случайно.

+0

Oh duh. Wow человек спасибо превосходно. – goldenratio

+0

Или если вы хотите немного больше случайности, чем это, ORDER BY number_of_uses + RAND() * 3 (или какая-либо другая константа смещения). – bobince

1

Я согласен с вашей интуицией в том, что использование хранимой процедуры - это правильный путь, но затем я почти всегда пытаюсь реализовать базу данных в базе данных.

В вашем proc я бы представил какую-то логику, например, скажем, есть только 30% -ый шанс, что возвращение результата фактически увеличит счетчик. Просто чтобы увеличить изменчивость.

+0

Это звучит неплохо. Мой следующий шаг - изучить ORM, например SqlAlchemy, который поддерживает sprocs (правильно?), И тогда я это реализую. На данный момент я все еще могу реализовать случайность увеличения счетчика в python. Благодаря! – goldenratio

Смежные вопросы