mvgfirst писал(а) 03. Мая 2008 :: 14:04:

Ответ неверный. С таким подходом можно отказаться, например, от ИТЗ. Я же ей не пользуюсь...

mvgfirst писал(а) 03. Мая 2008 :: 14:04:

Лицензия на SQL сервер уже ничего не стоит?

trad писал(а) 03. Мая 2008 :: 13:08:

Если подходить к вопросу с твоей логикой, то, в частности, парсер имен тоже нахрен не нужен. Потому что абсолютно весь его функционал можно реализовать КОПом. Однако ж, почему-то сделали парсер.

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

Uzhast писал(а) 04. Мая 2008 :: 01:56:
Да, так и есть. И подтверждение тому - AccountsRecordset.

Uzhast писал(а) 04. Мая 2008 :: 01:56:

Это отвлекает разработчика от глубокого погружения в структуру БД. Без понимания структуры БД невозможно написать качественные запросы. А структура БД в dbf и sql в некоторых ключевых местах очень разная.

Например журнал. Самое потребные данные в ней это позиция. Как написать унифицированный метазапрос для элементарного примера?
select
  docno as НомерДок,
  cast(left(date_time_iddoc,8) as datetime) ДатаДок
from $ОбщийЖурнал ($nolock)
order by date_time_iddoc

select
  docno as НомерДок,
  date as ДатаДок
from $ОбщийЖурнал ($nolock)
order by date, time, iddoc

Если делать "адекватную прослойку", то нельзя останавливаться на полумерах. Если идти до конца, то давай напридумываем кучу метаконструкций которые бы покрывали все возможные различия форматов. Например для вышеприведенного примера наряду с $ОбщийЖурнал понадобится покрыть позицию: $ПорядокПозицииПрямой, $ПорядокПозицииОбратный, $Дата, $Время, $ИДДокИзПозиции.
А сколько еще всего? А ссылки и отборы. А длинные строки...
Боюсь что в стремлении написать абсолютно абстрагированную от БД прослойку получиться штатный объект "Запрос". 

Дальше (можно не читать)... Получение иерархии с итогами по ней на стороне сервера - это преступление против сервера. Это задача клиента. Объяснить не смогу - потому как это религия скорее всего.

trad писал(а) 04. Мая 2008 :: 05:50:

А что ты можешь предложить для облегчения труда людей, у которых, например, в центральном офисе СКЛ, а на торговых точках - ДБФ. Или множество филиалов, где у кого СКЛ, а у кого ДБФ? В таких случаях люди ВЫНУЖДЕННО пишут без "глубокого" погружения в структуру БД. Предлагаешь забить на проблемы этих людей? Видишь только свою СКЛ базу, да?

И вообще, бизнес-логику надо писать, а не структуру базы изучать Если 1С++ необходимость изучения структуры базы сможет скрыть, то все только выиграют. Прикинь, приходит ламер, ставит новую 1С++ и пишет (нихрена не зная) запросы, работающие с той же скоростью, что у тебя после "глубокого изучения структуры БД"  (Впрочем, знатоки структуры БД, скорее всего, не выиграют )

trad писал(а) 04. Мая 2008 :: 05:50:

Давай, какие проблемы?

trad писал(а) 04. Мая 2008 :: 05:50:

Мда. Сколько приложений в мире написано и сколько пишется с нормальным DAL, без всяких тормозов и проблем... А в 1С++ что народ не пишет, все штатный "Запрос" получается...

trad писал(а) 04. Мая 2008 :: 05:50:

Скорее всего, религия. По тестам группировка прямыми запросами быстрее использования, например, ИТ на порядок. В ToySQL такие вещи также делаются на сервере запросами. И вроде жалоб на такое положение вещей я не встречал. Хотя, может быть, проблемы и есть

+
считаю что группирование в ИТ, с учетом получения родителей нижнего уровня в первичном запросе, с последующим получением остальных уровней иерархии отдельными запросами и подсчетом итогов на клиенте самым сбалансированным способом

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

Насколько  понял , так далеко пока речь не идет (а может и не дойдет). А вот предложенные в первом посте вещи действительно пригодятся, и если они будут, вроде никому не поплохеет