Как вычислить место (цифру), где находится запись в базе данных?

Id не учитываются.Они вида - dsgkl154657dfgdfgdfg.

0

sergeyilyin1984,

.. если вы все-таки решили вытаскивать индекс строки (из каких-то соображений), конвертируйте список в массив (.ToArray), и сортируйте его и потом обращайтесь уже к индексу, который есть у каждого уважающего себя массива ....

0

yurickas, Как?

0

sergeyilyin1984, выглядит так, как будто вы сами слабо понимаете, что просите. Если вам нужно "топ 5" записей, то их можно выдернуть в SQL через SELECT TOP 5 ..., а в EF (Core) через метод Take(5). Это даст вам первые пять записей.

Если вам нужна сортировка по какому-то критерию, то добавляйте её в запросе. Тогда записи вам вернутся в гарантированном порядке (каком запросите).

В самой СУБД никаких индексов у записей нет и выдумавать их не надо. ROW_NUMBER() и аналоги вам тоже на фиг не нужны, ибо записи придут в том порядке, в каком укажите. И позиция в выборке, где оказалась запись, и будет "местом (цифрой), где находится запись".

0

Usaga, Да понял я всё это!Мне нужно выдернуть не массив с индексами, а конкретную запись (точнее её номер).Например, это текущий пользователь и он находится на 52 строке.Его номер 52.Как выдернуть одну запись этого пользователя и сказать ему: "Заключённый 52!"?Пока остановился на хранимке с ROW_NUMBER(), которая возвращает номер строки в клиентский код.Но так как Вы не советуете использовать хранимки, то тогда варианты?

0

sergeyilyin1984, ещё раз: у данных в СУБД нет номеров строк. Порядок в котором записи хранятся не определён. ROW_NUMBER() просто назначает порядковые номера записям в выборке (то, что вы вытаскиваете запросом SELECT, а не то как оно всё это хранится). Этот порядок определяется условиями сортировки и отбора данных в запросе.

Сообщение от sergeyilyin1984 то тогда варианты?

Чётко озвучить требования. Без указания вашего видения решения.

0

Usaga,

Сообщение от Usaga sergeyilyin1984, ещё раз: у данных в СУБД нет номеров строк. Порядок в котором записи хранятся не определён. ROW_NUMBER() просто назначает порядковые номера записям в выборке (то, что вы вытаскиваете запросом SELECT, а не то как оно всё это хранится). Этот порядок определяется условиями сортировки и отбора данных в запросе.

Так я это и делаю в хранимой функции, которая сортирует и расставляет номера с помощью ROW_NUMBER() OVER(ORDER BY ...), а номер строки, при условии WHERE Users.Id = $1, возвращается в код C#.
Ладно, опишу требования.Есть игроки: Петя, Вася, Оля.Они занимают определённые места в игре.Сейчас поле рейтинга игроков имеет тип DateTime.Если один из игроков хочет занять первое место платно, то оплатив его, меняет дату на NOW.При ORDER BY он имеет приоритет по дате.Нужно сделать, так, чтобы текущий игрок всегда видел в приложении своё место (1 или 5 ...).Был совет -

Сообщение от sau от текущей даты вычитается изначальная дата , путем несложных подсчетов , можно узнать сколько прошло часов и кто на какой позиции должен быть

.Но мне кажется, что проще в хранимке посчитать строки и вернуть одну по Id.

0

sergeyilyin1984, ага, понял. Ну да. Просто решение в лоб - сортировка по рангу и подсчёт. Правда, при большом количестве игроков и низком рейтинге текущего игрока, это может работать не очень быстро (базе придётся перебирать все записи).

Правда для этого совершенно не обязательна процедура. Она тут ничего не ускорит.

Я бы не стал тут использовать дату. Если рейтинг игроков не зависит от очков и строго задаётся приложением, то лучше завести глобальный счётчик (Sequence) и брать оттуда последовательные значения для рейтинга пользователей.

Хотя такие решения позволяют игроку только на самый верх списка перемещаться. Если нужна возможность подниматься на одну ступень, а не только сразу вверх, то рейтинг должен выражаться простым счётчиком, не уникальным для всей таблицы (как сейчас, с датой).

0

Сообщение от Usaga Правда для этого совершенно не обязательна процедура. Она тут ничего не ускорит.

Usaga, Как тогда в EF Core использовать ROW_NUMBER()?Или тогда как вычислить номер строки?

Сообщение от Usaga Я бы не стал тут использовать дату. Если рейтинг игроков не зависит от очков и строго задаётся приложением, то лучше завести глобальный счётчик (Sequence) и брать оттуда последовательные значения для рейтинга пользователей.

То есть, нужно создать отдельную таблицу с рейтингом например от 1 до 10 и при оплате игроком, брать из неё значение 1, затем вставлять его в поле рейтинг таблицы игроки?

0

Сообщение от sergeyilyin1984 Как тогда в EF Core использовать ROW_NUMBER()?Или тогда как вычислить номер строки?

EF такое не позволит сделать не вытащив на клиент кучу данных. Выполните голый SQL-запрос. Придётся отсортировать игроков по рейтингу (дата это или значение счётчика - тут не важно) на убывание и завернуть это дела в другой запрос, вытаскивающий номер игрока по ID. Одним запросом такое не сделать. Или какую-то оконную функцию подтянуть, но я не уверен. Т.е. должен быть запрос над запросом.

Примерно такое:

Сообщение от sergeyilyin1984 То есть, нужно создать отдельную таблицу с рейтингом например от 1 до 10 и при оплате игроком, брать из неё значение 1, затем вставлять его в поле рейтинг таблицы игроки?

Последовательность (Sequence) объект отдельного вида. Не таблица. Это глобальный счётчик.

0

Тут позиция определяется по факту оплаты.
Можно конечно каждый раз перерасчитывать позиции , делать несколько запросов к БД , в том числе обновлять счетчик позиций для всех записей - но это медленное решение.

Что бы не трогать БД лишний раз, просто делаем один раз запрос к БД и выбираем всех пользователей у которых дата оплаты позже даты оплаты текущего юзера. , можно сразу count к записям применить , дабы вычислить позицию текущего юзера.

Можно просто вытянуть ТОП-10 оплативших , и там уже юзер сам видит входит он в топ или нет.

1

Сообщение от sau у которых дата оплаты позже даты оплаты текущего юзера.

Интересное решение, но страдает той же самой балячкой, что и мой вариант: если игрок имеет самый низкий рейтинг (раньше всех заплатил), то базе придётся вытащить\посчитать всех.

0

Сообщение от Usaga то базе придётся вытащить\посчитать всех.

Все не нужно , но запроса будет два . первым запросом выводим топ-10 записей сортированных по дате оплаты , если юзера в этом топе нет - это уже смотрим на клиенте по массиву из 10-ти записей , то делаем еще один уточняющий запрос к БД на определение его позиции , т.е select count(*) , результат будет не мильон записей , а одна - номер позиции текущего юзера не попавшего в ТОП-10.
Ну и еще для пущей оптимизации , у нас же в любом случае есть данные по текущему юзеру , можно посмотреть какая там дата , если разница между текущим днем и датой оплаты слишком большая . то даже запрос к БД не делаем , ибо юзера не интересует точность позиции 10001 или 20001 , просто выводим информацию шо он в жопе рейтинга.

1

sau, на самом деле, если бы использовался Sequence, то достаточно было бы посчтитать разницу между значением рейтинга текущего пользователя и максимальным значением рейтинга среди всех пользователей (мгновенно при наличии индекса по этому полю). Такое решение потребуте только один запрос и скорость будет молнееносной вне зависимости от количества игроков (хоть миллионы).

0

Или рейтинг представляем отдельной таблицей. Например нам интересно сделать список топ-10. Таблица имеет 10 фиксированный записей.
При выводе всех игроков, сначала выводим данные нашей таблицы топ-10 (на 10 записей не надо много тратить ресурсов), потом все остальные в любом удобном порядке.

Запись таблицы в топ-10 содержит: ид игрока, дату покупки места, дату после которой игрок вылетает из списка. При формировании списка нам надо только найти 10 игроков в базе и сделать список.

При оплате места, мы имеем информацию, доступно это место или нет для оплаты. Если доступно, то какие действия предпринимаем с текущей позицией (понижаем на позицию вниз или выкидываем в общий список) и т.д.

Ну, как-то так.

0

Сообщение от Usaga au, на самом деле, если бы использовался Sequence, то достаточно было бы посчтитать разницу между значением рейтинга текущего пользователя и максимальным значением рейтинга среди всех пользователей

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

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

0

sau, нет. Только тому, кого повышаем.

0

sau, Позиция игроков должна определяться всегда.Например, только что зарегистрированный игрок сразу попадает в топ.Дата регистрации копируется в рейтинг по датам.Свою позицию игрок должен видеть всегда и везде в приложении.

0

sau, хотя нет, вы правы. Одни и теже игроки несколько раз повышаться могут. Тогда разница в счётчике не будет соответствовать разнице в количестве игроков.

Добавлено через 5 минут
sergeyilyin1984, заведите в базе несколько тысяч записей с рандомными рейтингами и примерьте варианты, что тут озвучены были мной и господином sau. Посмотрите на сколько быстро (или медленно) отрабатывают наихудшие ситуации с определением рейтинга самого "низкого" пользователя. Вполне возможно, что будет достаточно быстро на первое время.

А дальнейшие оптимизации уже можно будет вырабатывать по мере надобности, а не заранее.

0

Сообщение от sergeyilyin1984 Позиция игроков должна определяться всегда.

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

Но , у Вас то либо топ-1 , либо его текущая позиция , а какая она по факту - без разницы т.к этот численный показатель ровным счетом ни на что не влияет., можно просто случайное число выдать если юзер по дате в ТОП-10 не попал , он же не полезет в БД кол-во реальных записей проверять. Условия задачи должны быть осмысленны , а не просто потому шо как у всех ).

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

0

.. вот ради интереса попробовал .. поскольку ТС тяготеет с SQL-коду и хранимкам ... вот такая хранимка обновляет и дату (поле paydate), и рейтинг(поле rating) без каких-либо трудностей, но на паре десятков записей .. будет ли это тормозить в Лас-Вегасе - вопрос ... .. userid от фонаря, но подразумевается, что он как-то передается параметром ...

0