Здравствуйте, Undying, Вы писали:
U>Здравствуйте, SE, Вы писали:
SE>>Если у нескольких сотен пользователей вдруг возникает непреодолимое желание разглядывать отчеты на пару миллионов записей (нафига? но ведь хотят!) и вертеть их и так и эдак, причем каждый отчет специфичен для пользователя и так по двадцать отчетов одновременно, то опыт показывает, что при разгильдяйском отношении к памяти, память заканчивается раньше.
U>И чем тут поможет последовательная загрузка строк таблицы? Если отчет хранит данные, то он все равно сожрет немерянно памяти. Тут надо делать честный виртуальный режим, который будет подгружать только то, что видит пользователь на экране.
О том и речь. В результате бизнеслогика все равно переместится на сторону БД, причем, если количество данных не будет известно зарание, то выяснится это только на продакшене.
В общем, для себя отметил, что оба приведенных примера бессмысленны без знания контекста задачи.
Здравствуйте, SE, Вы писали:
SE>О том и речь. В результате бизнеслогика все равно переместится на сторону БД, причем, если количество данных не будет известно зарание, то выяснится это только на продакшене.
Хотя я не понимаю зачем пользователю показывать пару миллионов строк, наиболее разумное решение отсечь 1000-10000 верхних, а остальное отбросить. Неужто заказчик грудью стоит за то что ему все 2 миллиона строк нужны? Заказчик реальной работой вообще не занимается что ли?
Здравствуйте, dmz, Вы писали:
dmz>Оно еще и по сети будет передаваться, если СУБД на другом сервере. Т.е. на самом деле этот код пытается выполнять задачу СУБД dmz>вместо нее, едва ли эффективно, при этом.
А если sql-запрос использовать оно через астрал начнет передаваться? Ты о чем вообще?
dmz>А какие преимущества у этого кода, кроме того, что он понятен лично вам? Мне вот SQL понятен сразу, а приведенный код требует dmz>вникания в каждую строчку (которых, повторюсь, еще и больше).
Это тебе к avpavlov'у. Это он говорил, что с таким sql'ем могут работать немногие программисты, поэтому большинство программистов приходится отсеивать на собеседовании. Я не знаю прав прав avpavlov или нет, но знаю, что с кодом который я привел вчерашние студенты работают влегкую.
U>Это тебе к avpavlov'у. Это он говорил, что с таким sql'ем могут работать немногие программисты, поэтому большинство программистов приходится отсеивать на собеседовании. Я не знаю прав прав avpavlov или нет, но знаю, что с кодом который я привел вчерашние студенты работают влегкую.
В Яве есть нечто похожее — называется Hibernate, как раз позволяет студентам легко работать с базой данных. Настолько легко, что они даже не понимают, что на самом деле происходит. Вот в твоём примере происходит NxM запросов к базе, вместо одного — а они этого даже не поймут.
Здравствуйте, Undying, Вы писали:
U>Здравствуйте, SE, Вы писали:
SE>>О том и речь. В результате бизнеслогика все равно переместится на сторону БД, причем, если количество данных не будет известно зарание, то выяснится это только на продакшене.
U>Хотя я не понимаю зачем пользователю показывать пару миллионов строк, наиболее разумное решение отсечь 1000-10000 верхних, а остальное отбросить. Неужто заказчик грудью стоит за то что ему все 2 миллиона строк нужны? Заказчик реальной работой вообще не занимается что ли?
Да. Вот нужны и всё. Причем все два миллиона на одной странице. Заказчики иногда такие заказчики...
Заказчика из моей истории остановил лишь тот аргумент, что один пиксель скролбара соответствовал нескольким тысячам строк. Т.е. при всем желании ни о какой адекватной навигации речь не шла.
Здравствуйте, avpavlov, Вы писали:
A>В Яве есть нечто похожее — называется Hibernate, как раз позволяет студентам легко работать с базой данных.
Хибернейт очень тяжелая ОРМ, поэтому редкостная гадость. У меня ОРМ сверх легкая и соответственно совершенно прозрачная.
A>Настолько легко, что они даже не понимают, что на самом деле происходит. Вот в твоём примере происходит NxM запросов к базе, вместо одного — а они этого даже не поймут.
В моем примере происходит столько запросов сколько выбирается табличек, т.е. всего там три запроса.
A>Ну ещё, кстати, ты так и ответил на мои вопросы
A>здесь: http://www.rsdn.ru/forum/job/4345302.1.aspx
A>>Настолько легко, что они даже не понимают, что на самом деле происходит. Вот в твоём примере происходит NxM запросов к базе, вместо одного — а они этого даже не поймут.
U>В моем примере происходит столько запросов сколько выбирается табличек, т.е. всего там три запроса.
RowLink people = people.FindRow(PeopleType.ByGenderAndEthnic, genderCode, ethnicCode);
Если это не запрос к базе, то что? И вообще, переменная people не объявлена нигде
Здравствуйте, avpavlov, Вы писали:
A>и в догонку — допусти есть поле spouseId (супруг) которое ссылается на эту же таблицу. Оно может быть НУЛЛ (не женат/не замужем). Как будет выглядеть запрос "получить список имён людей и имён их супругов, если супруг есть"?
По уму как-то так:
(Select * From people Where ...) selectPeople;
(Select * From people Where people_id in (select spouseId From selectPeople)) spousePeople;
Но я не умею из программы получать две таблички одним запросом (это вообще возможно?), поэтому на практике либо формирую второй запрос из программы после отработки первого (если уверен, что количество элементов в in будет не слишком велико), либо использую первый запрос в качестве вложенного во втором запросе.
Связывание между выбранными людьми и их супругами сделаю через словари, аналогично предыдущей задаче.
Здравствуйте, avpavlov, Вы писали:
U>> RowLink people = people.FindRow(PeopleType.ByGenderAndEthnic, genderCode, ethnicCode);
A>Я вот ещё сразу не вчитывался, сейчас только внимательно посмотрел. Прокомментируй этот код, пожалуйста. Это на каждый вариант поиска придётся иметь ByXXX? А если условие хоть чуть более сложное чего делать? Например, поиск по OR(или).
Индекс это словарь, т.е. он может помочь только когда ключу соответствует одна или несколько строк. Записывается он одной строчкой кода, можно это делать по месту:
MultiIndexBlank byGenderAndEthnic = new MultiIndexBlank(PeopleType.Gender, PeopleType.Ethnic);
Бинарный поиск сейчас TableLink не поддерживает, т.к. как-то редко надо было в полученной выборке искать что-то в отсортированной коллекции. Соответственно если с такой задачей встречусь, то решу ее внешним образом, через сортировку tableLink.AllRows и бинарный поиск в полученной коллекции. Но в принципе и в tableLink еще один вид индекса добавить недолго.
A>Ещё жизненный случай — есть студент, у него указана планируемая дата начала и окончания учёбного курса. А есть ещё поле когда он реально начал. Когда это поле пусто, то используется планируемая дата. A>Таким образом поиск получается что-то вроде where coalesce(actualStartDate,plannedStartDate) = ... A>Как это будет записано в твоём фрэймворке?
А в полном варианте можешь задачу привести? Если задача состоит в том, чтобы выбрать всех студентов с временем начала учебы в таком-то диапазоне, то я ее средствами sql буду решать, передав соответствующий запрос в конструктор TableLink'а. Я не люблю мержить таблицы средствами sql (т.к. считаю это сложным), а фильтрацию строк лучше делать sql'ем, благо это обычно достаточно просто. Т.е. общий принцип такой, если средствами sql можно значительно сократить количество выбираемых строк, то это надо делать, операции же не сокращающие количество строк, а преобразующие их лучше делать в программе.
Здравствуйте, avpavlov, Вы писали:
A>RowLink people = peopleLink.FindRow(PeopleType.ByGenderAndEthnic, genderCode, ethnicCode); A>Если это не запрос к базе, то что? И вообще, переменная people не объявлена нигде
Извиняюсь за опечатку, там должно быть выделенное.
Это поиск в полученном DataTable. При создании TableLink мы указываем какие индексы (словари) нам нужно построить по полученному DataTable. Соответственно FindRow это просто обращение к словарю.
U>(Select * From people Where ...) selectPeople;
U>(Select * From people Where people_id in (select spouseId From selectPeople)) spousePeople;
U>
U>Но я не умею из программы получать две таблички одним запросом (это вообще возможно?), поэтому на практике либо формирую второй запрос из программы после отработки первого (если уверен, что количество элементов в in будет не слишком велико), либо использую первый запрос в качестве вложенного во втором запросе.
U>Связывание между выбранными людьми и их супругами сделаю через словари, аналогично предыдущей задаче.
U>По уму как-то так:
Нет, по уму как то так
select people.Name, spouse.Name
from
people
left join people spouse on spouse.id = people.spouse_id
U>либо использую первый запрос в качестве вложенного во втором запросе.
А как это на уровне твоего ОРМ сделать? Как в указанном в предыдущем посте коде? 2 таблицы вытащить в память и объединить в программе? И всё ради того, чтобы не учить джойны?
Здравствуйте, avpavlov, Вы писали:
A>А как это на уровне твоего ОРМ сделать? Как в указанном в предыдущем посте коде? 2 таблицы вытащить в память и объединить в программе? И всё ради того, чтобы не учить джойны?
Раньше я и знал, и активно использовал join'ы. Однако когда ты поднял тему про sql, я с некоторым удивлением обнаружил, что неиспользовал join'ы уже очень давно, т.к. на практике почти всегда мерж в памяти оказывается понятнее и удобнее.
Здравствуйте, avpavlov, Вы писали:
U>> т.к. на практике почти всегда мерж в памяти оказывается понятнее и удобнее. A>Я даже не знаю что тут возразить. А если таблицы на десятки тысяч строк? А если на сотни тысяч?
Какая разница? В память выбираются только те строки, которые нужны по условию задачи.
