Задача проста - выбрать одну случайную строку из таблицы.
В таблице нет PK, поэтому просто сделать в программе random id не получится.
Также, не хотелось бы использовать udf.
Вроде, такое должно как-то решаться средствами сервера... Но что-то я не нашел.
Помогите, пожалуйста.
Выбрать одну случайную строку
нету в множествах такого понятия как "случайная строка". тем более если запись нечем идентифицировать.
могу сгенерить тебе случайную дату и случайное слово. По ним выбери что-нибудь из БД:
'10.11.1999'
"пардон"
интересно, каким же это образом не имея ПК можно выбрать "случайную" запись при помощи UDF?Также, не хотелось бы использовать udf.
могу сгенерить тебе случайную дату и случайное слово. По ним выбери что-нибудь из БД:
'10.11.1999'
"пардон"
Ну как везде пишут (в темах, посвященных этому вопросу):
Т.е записи отсортируются по случайному значению... Вроде как это то что надо, но очень хочется обойтись без UDF.
Еще, я так понимаю, чтобы ограничить кол-во возвращаемых записей, нужно использовать first(1)?
UPD Да, еще забыл сказать: таблица состоит из одного поля (FK), т.е. значения там уникальные, но никакого порядка нет. Нужно взять одно из них.
Можно конечно тупо прочитать все значения в массив, и уже в программе выбрать одно, но мне такой вариант вообще не нравится.
Код: Выделить всё
select ... order by rand()Еще, я так понимаю, чтобы ограничить кол-во возвращаемых записей, нужно использовать first(1)?
UPD Да, еще забыл сказать: таблица состоит из одного поля (FK), т.е. значения там уникальные, но никакого порядка нет. Нужно взять одно из них.
Можно конечно тупо прочитать все значения в массив, и уже в программе выбрать одно, но мне такой вариант вообще не нравится.
-
belov-evgenii
- Сообщения: 52
- Зарегистрирован: 28 сен 2007, 10:19
пишем автоматизацию розыгрыша лотереи?
только там нужны "случайные" записи.
rand - это udf. да, order by можно. но order by - сортировка массива записей, т.е. затраты могут зависеть от объема записей.
никакого порядка у записей обычно нет, пока не дать order by.
порядок может случайно возникнуть при физическом хранении записей. но может и измениться со временем.
только там нужны "случайные" записи.
rand - это udf. да, order by можно. но order by - сортировка массива записей, т.е. затраты могут зависеть от объема записей.
уникальные значения только в ПК.таблица состоит из одного поля (FK), т.е. значения там уникальные, но никакого порядка нет.
никакого порядка у записей обычно нет, пока не дать order by.
порядок может случайно возникнуть при физическом хранении записей. но может и измениться со временем.
Re: Выбрать одну случайную строку
Код: Выделить всё
select first 1 skip :RAND * from ...Re: Выбрать одну случайную строку
Спасибо, заработало!Slavik писал(а):В параметр :RAND на клиенте пихаешь случайное целое число от нуля до количества записей в таблице минус одну. И не надо никаких order by.Код: Выделить всё
select first 1 skip :RAND * from ...
kdv - нет, это не лотерея. Это что-то вроде плеера в случайном режиме воспроизведения.
А почему уникальные значения только в PK?
У меня таблица создается так:
Код: Выделить всё
create table "Tracks1" ("id" int UNIQUE REFERENCES "Tracks")неправильно. учи матчасть. В соответствии с нормальными формами идентификатор записи называется Первичный Ключ (Primary Key). Любые другие столбцы, могущие также идентифицировать запись, но являющиеся ВТОРОСТЕПЕННЫМИ "идентификаторами", типа "номер паспорта", называются АЛЬТЕРНАТИВНЫМИ ключами. Для них и используется constraint UNIQUE.А почему уникальные значения только в PK?
У меня таблица создается так:
Который по стандарту ДОПУСКАЕТ НАЛИЧИЕ NULL, в отличие от Primary Key.
кроме того, references - это неявный Foreign Key.
Так что на самом деле ты создал
1. неименованный constraint unique
2. неименованный constraint foreign key
И дальше советую разрабатывать без идиотских двойных кавычек.
http://www.ibase.ru/ibfaq.htm#dtproblem
ОК, с pk и fk разобрались
Про это я знаю, кажется это описано в release notes, т.е. это штатное поведение системы. И наверное название парагрфа "Проблема с именами объектов в двойных кавычках в 3-ем диалекте" не совсем корректно.kdv писал(а):И дальше советую разрабатывать без идиотских двойных кавычек.
http://www.ibase.ru/ibfaq.htm#dtproblem
Тут скорее не проблемы, а особенности работы... Я привык их везде писать, и проблем с этим нет. Правда, смысла их использовать в общем-то нет. Мне в кавычках легче увидеть названия полей/таблиц и т.п. - пишу в Delphi, там подсветки SQL кода в строковых переменных нет.kdv писал(а):корректно. Двойные кавычки дают указанные проблемы. Если не согласен - докажи обратное.не совсем корректно.
Я в курсе, что двойные кавычки в третьем диалекте были придуманы в IB 6.0. Однако пока ничего кроме проблем от них нет.
а ты его прямо в Delphi пишешь?
, а где еще можно? Проверка и отладка выполняется после запуска самой программы.