Delphi 2005

← →
Суслик © (2004-12-06 11:43) [0]

Предлагаю в данном топике вести обсуждение новой версии Delphi.

Я не модератор, но как автор ветки могу попросить стараться сдерживать эмоции и постить только проверенную информацию, а не домыслы :))) Заранее спасибо.

Установив триал я пытался сбилдить старый win32 проект.
Результаты:

1. Более 200 тыс строк у меня просто не билдится. Доходит до 200 и
все - жесткое снятие среды delphi :(

2. Некоторые файлы проекта открываются в бинарном виде. Выяснить почему так я не с мог. Смена file format в меню результата не дает.

3. Некоторые синтаксические конструкции не билдятся. Например такая
const c = 10; var a: array[c+2{ошибка тут}...c+10] of integer;

ВОПРОС.
Может кто-нибудь прокоментировать проблемы в п.п. 1..3?

← →
Dmitriy O. © (2004-12-06 11:46) [1]

По пункту 1 может это ограничение триала ?
По теме хотелось бы надыбать этот Delphi 5.
И желательно не триал и не за кило баксы это возможно ?

← →
Суслик © (2004-12-06 11:47) [2]

> По пункту 1 может это ограничение триала ?

Ограничения обычно явно оговариваются. Но не через out of memory и снятие задачи.

ЗЫ.
Скажу честно, что т.к. сменился формат мануала, то я не очень в нем разобрался. Вполне возможно, что в мануале это все оговорено...

← →
by © (2004-12-06 11:51) [3]

Суслик © (06.12.04 11:43)
2. Некоторые файлы проекта открываются в бинарном виде. Выяснить почему так я не с мог. Смена file format в меню результата не дает.

Может это ?
http://www.delphikingdom.com/asp/viewitem.asp?catalogid=1091
http://www.delphikingdom.com/asp/viewitem.asp?catalogid=1091#03-7

Русские буквы в комментариях к коду
Поначалу неприятно удивило открытие файлов кода с комментариями в заголовке, написанными русскими буквами в кодировке Win1251. Часть таких файлов открываются, как двоичные. После небольшого исследования оказалось, что портит все маленькая буква "я" в тексте комментариев в начале модуля. Если в новой среде написать такой комментарий в начале модуля, то он редактиреутся нормально. Но, если его закрыть, то вновь откроется он в двоичном виде. По-видимому, проблема связана с тем, что редактор кода по первой порции фиксированного объема определяет формат файла. Встречая в этой порции букву "я" (ее код $FF), редактор некорректно определяет формат файла. При переносе текста с буквой "я" в конец файла или в середину файла большого размера, его формат определяется корректно.

Сходная ситуация обсуждалась в Подводных камнях.
Проблема с открытием таких файлов решается или удалением слов из заголовка модуля, содержащих маленькую букву "я", или замена ее на букву "Я" в верхнем регистре. Кому что нравится.

Русские буквы в названиях каталогов проекта
Проекты VCL.NET и WinForms не запускаются из-под среды, если в полном имени каталога проекта есть русские буквы. Среда сообщает "Unable to create process".

К сожалению, ссылки в окне "Help Insight" не будут работать, если у вас в названии каталогов используются русские буквы.

← →
by © (2004-12-06 11:52) [4]

Dmitriy O. © (06.12.04 11:46) [1]
У китайцев найдется все ))

← →
Dmitriy O. © (2004-12-06 11:53) [5]

> Но не через out of memory и

Так значит при компиляции поглощается системная память ?
Возможно с этим связано требование о 516 мб ? Типа Delphi
размещает бинарник не не диске а в оперативной памяти. Для быстроты компиляции. Как скажем это делает VB
> По теме хотелось бы надыбать этот Delphi 5.

Звиняйте Delphi 2005

← →
Суслик © (2004-12-06 11:55) [6]

> [5] Dmitriy O. © (06.12.04 11:53)

Виноват, забыл сказать - у меня гиг памяти

← →
Anatoly Podgoretsky © (2004-12-06 11:57) [7]

by © (06.12.04 11:51) [3]
Американцы искренне верят, что символов с кодом 255 не бывает в природе.

← →
Dmitriy O. © (2004-12-06 12:18) [8]

Ну что все оплохом. Тов Суслик а поделитесь позитивом от Юзания Delphi 2005 если смысл переходить на него с Delphi 6 ?

← →
Суслик © (2004-12-06 12:21) [9]

Какой позитив, если проект не билдится :((

← →
Dmitriy O. © (2004-12-06 12:24) [10]

> Суслик © (06.12.04 12:21) [9]

Не страшно. Мож не билдится тока этот. Вы другие пробовали ?.
И потом я имею в виду удобнелие в нем работать чем в D6 ?

← →
ghg © (2004-12-06 12:31) [11]

судя по обзору на королевстве стало гораздо удобнее работать, но пока не буду так как нужные мне компоненты еще не перелопалити под D2005

← →
blackman © (2004-12-06 12:35) [12]

А в чем прелесть Delphi 2005 ? Т.е. вообще зачем переходить ?
Что будет лучше :) 6 как мне кажется вполне достаочно. Ведь и 7 не содержала ничего принципиально нового. Что же в Delphi 2005 ? Те же ошибки, только под новым флагом ? :-)

← →
Dmitriy O. © (2004-12-06 12:37) [13]

> blackman © (06.12.04 12:35) [12]

Ну а зачем было переходить на Word если и под Лексиконом можно было работать.
Или еще зачем покупать Форд-фокус если и на Десятке ездить можно ?
Просто человеку свойственно стремление к прекрасному. Даже если в этом нет необходимости.

← →
Игорь Шевченко © (2004-12-06 12:41) [14]

Суслик © (06.12.04 12:21) [9]

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

← →
ghg © (2004-12-06 12:45) [15]

лично мне очень импонирует в D2005 три вещи:
1) возможность сворачивать куски текста {$region}
2) встроенный контроллер версий
3) встроенный тестировщик

ну и то что и под Net можно писать не ставя новую IDE

← →
Суслик © (2004-12-06 12:46) [16]

> [14] Игорь Шевченко © (06.12.04 12:41)

Я так понимаю, что не только я столкнулся с глюками?

Среда мне понравилась. Особенно интеграция со starteam. Это очень хорошо.

← →
Суслик © (2004-12-06 12:52) [17]

> [15] ghg © (06.12.04 12:45)

Мне тоже среда понравилась, но какой смысл в среде, если она не поддерживает обратную совместимость :((

← →
Игорь Шевченко © (2004-12-06 12:53) [18]

Суслик © (06.12.04 12:46) [16]

В Quality Central зайди и увидишь, что не только ты.

> Среда мне понравилась

Да, мне тоже после нее старая показалось блеклой и неудобной

← →
Agent13 © (2004-12-06 12:54) [19]

> По теме хотелось бы надыбать этот Delphi 5.
> И желательно не триал и не за кило баксы это возможно ?

Ослом как всегда можно закачать, но качать будешь долго :(
А вообще, где-то в инете ходил слух, что всё-таки обещают в начале 2005 года выпустить и персональную версию. Но как известно, обещанного борландом 100 лет ждут. Кто-нибудь слышал подобное? Или опять придётся пираЦтвом заниматься...

← →
Dmitriy O. © (2004-12-06 12:59) [20]

> Или опять придётся пираЦтвом заниматься...

Дак придется хотя у нас стало трудно. Толи нет спроса толи че
Но всякий софт исчезает из продажи. Так раньше Delphi была в любом магазине CD щас нет

← →
DiamondShark © (2004-12-06 13:27) [21]

> Обещают в декабре выложить update

К тому времени триал период кончится.

Сломать что-ли лицензилку?

← →
Johnmen © (2004-12-06 13:39) [22]

>DiamondShark © (06.12.04 13:27) [21]
>Сломать что-ли лицензилку?

Зачем ? Кряков уже полно в инете...:)

← →
by © (2004-12-06 13:52) [23]

Johnmen © (06.12.04 13:39) [22]
Да и не триалы тоже лежат ))
Вот только весят много.

← →
Суслик © (2004-12-06 13:54) [24]

> Сломать что-ли лицензилку?

Смысл во всем этом, если портировать не удается.

Все-таки остается вопрос - почему половина файлов из старого проекта открывается в виде бинарника. При том, что иногда и модули из нового проекта (т.е. созданного в дельфи 2005) также открываются в виде бинарника.

← →
Игорь Шевченко © (2004-12-06 13:57) [25]

Суслик © (06.12.04 13:54) [24]

Убери русскую букву я из исходников

← →
ghg © (2004-12-06 13:57) [26]

можно еще раз про портирование проектов
то есть старые проекты win32 я не смогу откомпилить в D2005 ?

← →
Суслик © (2004-12-06 13:59) [27]

> [25] Игорь Шевченко © (06.12.04 13:57)

Думаешь?
Я тоже понял, что это от крусских букв зависит. Вот только не понял по какому принципу.

Как тебе удалось это выяснить?

> [26] ghg © (06.12.04 13:57)
> можно еще раз про портирование проектов
> то есть старые проекты win32 я не смогу откомпилить в D2005
> ?

Судя по доке, можешь. Но у меня не вышло - память кончается и кирдык.

← →
DiamondShark © (2004-12-06 14:07) [28]

> Я тоже понял, что это от крусских букв зависит. Вот только
> не понял по какому принципу.

Код "я" -- $ff
Злые американе считают, что в нормальном тексте этому символу делать нефиг (в ASCII -- это какой-то непечатный символ, а в Юникоде -- byte order mark).

← →
Игорь Шевченко © (2004-12-06 14:08) [29]

Суслик © (06.12.04 13:59) [27]

http://www.delphikingdom.com/asp/viewitem.asp?catalogid=1091

← →
DiamondShark © (2004-12-06 14:09) [30]

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

← →
blackman © (2004-12-06 14:11) [31]

Так все таки, кто-то может кратенько описать преимущества 2005 или все юзают ее только ради "стремление к прекрасному. Даже если в этом нет необходимости" ? :)

← →
Суслик © (2004-12-06 14:16) [32]

Также не было бы проблемы, если потом можно было бы явно менять формат.
File format в конектном меню у меня не работает.

← →
Суслик © (2004-12-06 14:17) [33]

> а в Юникоде -- byte order mark).

обычно это либо первый, либо второй символ (вроде).

← →
DiamondShark © (2004-12-06 14:18) [34]

Кстати, может кто-то объяснить, из каких таких соображений рефакторинг не работает внутри with?

← →
Суслик © (2004-12-06 14:20) [35]

Выдержка из статьи, которую советовал Игорь Шевченко:

"Проблема с открытием таких файлов решается или удалением слов из заголовка модуля, содержащих маленькую букву "я", или замена ее на букву "Я" в верхнем регистре. Кому что нравится."

А вот не фига, кстати, у меня есть файлы, которые открываются бинарниками, если первый комментарий стоит после type в interface. Убираешь комментарий, все ок.

← →
Суслик © (2004-12-06 14:27) [36]

В качестве дока-ва [35]. Такой код у меня открывается как бинарник (модуль урезан).

UNIT MLSFPay; INTERFACE USES Graphics, Classes, ActiveX, kernClasses, ErrorHandling, MLObject, MLAlternatives, Kern; TYPE // Структура для хранения ссылок на поля покрытий TMLSFPay_PropRec = record NdsRate, // Ставка Book, // Признак включенности в книгу // Остаток до распределения BeginCost, // Сумма

← →
Игорь Шевченко © (2004-12-06 14:32) [37]

Суслик © (06.12.04 14:27) [36]

> // Структура для хранения ссылок на поля покрытий

Убрать трудно ?

← →
Суслик © (2004-12-06 14:36) [38]

> [37] Игорь Шевченко © (06.12.04 14:32)

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

← →
DiamondShark © (2004-12-06 14:43) [39]

Круто.

Пытался определить, какую порцию текста среда использует для определения формата файла.

Взял большой (не очень) текстовый файл, без "я".
Открыл. Текст.
Вставил блокнотом "я" где-то в начале.
Бинарный.
Вставил в конце. Текстовый.
Ну дальше понятно -- дихотомией ищем границу.

Где-то на 5-6 открытии файла -- Access violation in borlndmm.dll

;)

Крепко хранит среда свои секреты.

← →
Суслик © (2004-12-06 14:46) [40]

> Access violation in borlndmm.dll

в этой библиотеке (если запомнил верно) я видел несколько багов, и все AV :(((

← →
DiamondShark © (2004-12-06 14:47) [41]

Гы :)
Таки, узнал.
Первые 256 байт.

Кто бы мог подумать...

← →
vuk © (2004-12-06 14:50) [42]

to DiamondShark © (06.12.04 14:43) [39]:
До 4-й позиции от начала файла наличие "я" в тексте роли не играет.

← →
iZEN © (2004-12-06 14:51) [43]

by © (06.12.04 11:51) [3]
портит все маленькая буква "я" в тексте комментариев в начале модуля. Если в новой среде написать такой комментарий в начале модуля, то он редактиреутся нормально. Но, если его закрыть, то вновь откроется он в двоичном виде.
Вот так лажа. Не ожидал я такого от Borland.
Русские буквы в названиях каталогов проекта Проекты VCL.NET и WinForms не запускаются из-под среды, если в полном имени каталога проекта есть русские буквы. Среда сообщает "Unable to create process".
Дык это, когда .Net копировали с Java, скопировали и эту фичу. ;)))
К сожалению, ссылки в окне "Help Insight" не будут работать, если у вас в названии каталогов используются русские буквы.Вот такая вот селява...

← →
by © (2004-12-06 14:54) [44]

offtop
Идет целенаправленная политика уничтожения буквы "я" )))
Не дадим Борланду покусится на xfcnm алфавита, а то скоро и до других букв у них руки дойдут ))
offtop

← →
by © (2004-12-06 14:54) [45]

xfcnm = часть

← →
Суслик © (2004-12-06 14:56) [46]

вообще говоря, "я", "ю" и прочие буквы все фигня - буду на англицком писать, а вот то, что у меня только 20% проекта сбилдилось действительно пугает.

Пытался ли кто билдить проекты более 200 тыс строк?

← →
iZEN © (2004-12-06 15:01) [47]

/**Суслик © (06.12.04 14:46) [40]
> Access violation in borlndmm.dll
в этой библиотеке (если запомнил верно) я видел несколько багов, и все AV :(((
*/
Это пока семачки. Всё ещё впереди.

В .Net нет объявленных исключений, принуждающих к обработке как в Java: void someMethod(...) throws SomeException {...} AV или что-то похожее рано или поздно вылезит неизбежно.

← →
vuk © (2004-12-06 15:01) [48]

<offtopic>
to iZEN © (06.12.04 14:51) [43]:
>Дык это, когда .Net копировали с Java, скопировали
>и эту фичу. ;)))
А в каких местах его скопировали?
</offtopic>

← →
DiamondShark © (2004-12-06 15:03) [49]

> vuk © (06.12.04 14:50) [42]
> to DiamondShark © (06.12.04 14:43) [39]:
> До 4-й позиции от начала файла наличие "я" в тексте роли
> не играет.

А в 5-й позиции влияет.
Фича.

Правда, если текст сохранить в UTF-8, то уже никакие "я" не страшны.

← →
Игорь Шевченко © (2004-12-06 15:09) [50]

DiamondShark © (06.12.04 15:03) [49]

А в старых версиях его потом возможно загрузить ?

С уважением,

← →
DiamondShark © (2004-12-06 15:11) [51]

> В .Net нет объявленных исключений, принуждающих к обработке
> как в Java: void someMethod(...) throws SomeException {...}

Во-первых, при чём тут НЕТ?
Во-вторых, нафиг эта дурь нужна?

← →
vuk © (2004-12-06 15:11) [52]

А я люблю исходники из FAR-а смотреть...

← →
DiamondShark © (2004-12-06 15:16) [53]

> Игорь Шевченко © (06.12.04 15:09) [50]

Загрузить можно.
Скомпилировать нельзя. ;-)

← →
iZEN © (2004-12-06 15:24) [54]

To vuk © (06.12.04 15:01) [48]
В имени пакета java не должно быть символов не английского алфавита. Пакет в java является частью пути к файлу класса.
Кстати, название типа Java не может быть неанглийским, хотя в именах идентификаторов и методов допускается использование любых unicode-символов (В 1998г. в JBuilder 1&2 я писал программы, используя русские идентификаторы и имена методов и всё прекрасно работало, вот).

to DiamondShark © (06.12.04 15:11) [51].
А как же совместимость?! .Net - это теперь база для Delphi.
Не будет вам никаких исключений, обязательных к обработке:
http://www.optim.ru/cs/2001/1/clr/c-sh.asp
Вас никто не заставляет обрабатывать хоть какие-то исключения. Как сказал один из сотрудников Microsoft, в том, что разработчики вынуждены обрабатывать исключения, больше вреда, чем пользы. Это приводит к большому количеству catch (Exception e)-обработчиков исключений, не делающих ничего полезного.

Есть мнение, что это неудачное решение, поскольку оператор throws делает очевидным, какие исключения возбуждаются методом и являются частью контракта метода. Иначе вы вынуждены читать исходный код вызываемого метода, чтобы узнать, какие исключения могут быть возбуждены. Но нам кажется, что при грамотной реализации такое решение может упростить программирование. Время покажет.

← →
Суслик © (2004-12-06 15:32) [55]

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

Граждане, ну неужели ни у кого нет проекта более 200 тыс строк? А?

← →
Суслик © (2004-12-06 15:38) [56]

С ECO разбарался кто-то?
Как впечатления?

← →
Sergey_Masloff (2004-12-06 15:41) [57]

Суслик © (06.12.04 15:32) [55]
>Граждане, ну неужели ни у кого нет проекта более 200 тыс строк? >А?
Проекты есть. Нет времени на страдание ерундой ;-)
Нет, серьезно, в упор не понимаю необходимости установки D2005 и попыток на нее что-то переносить. Просто из спортивного интереса?

← →
by © (2004-12-06 15:42) [58]

Суслик © (06.12.04 15:38) [56]
Тут недавно в ветке об UML ECO подверглись критике, хотя Борланд настойчиво пытается впихнуть все это разработчику. Задумка интересная, типа чтобы голова не болела как объекты сохранять в БД, persistent layer. Но вот как оно будет работать, особенно на больших объемах. Хотя где-то резонно заметили, что если у вас в приложении двигаются большие объемы данны, то стоит задуматься об архитектуре.

← →
Суслик © (2004-12-06 15:43) [59]

> [57] Sergey_Masloff (06.12.04 15:41)

Ты слышал, что С. Орлик говорил недели две назад (можешь поиском поискать)?

"Life time delphi 6 кончился."

← →
by © (2004-12-06 15:44) [60]

Sergey_Masloff (06.12.04 15:41) [57]
Ну спортивный интерес и желание нового тоже присутствует, но больше конечно новые возможности редактора прельщают, плюс одна среда для win32 и .Net. Но пока рановато переходить, так как еще не все компоненты есть для 2005.

← →
Sergey_Masloff (2004-12-06 15:45) [61]

Зря конечно я в этой ветке. Но все же не удержусь еще камень в борландовский огород:

>С ECO разбарался кто-то?
Ага. "Клиент-серверная" технология в терминах Борланд. Под "К-С" понимается использование сервера как набора таблиц, то есть технология фокспро и парадоксов в своем абсолютном выражении. На фига хранимые процедуры и триггеры, можно ж все написать дельфовым кодом. Эффективность? А зачем она на современных крутых тачках!!!! Ах, не зватает даже крутых тачек? Так это неправильно технологию выбрали! Для пацанских приложений только трехзвенка!
Вобщем, ECO это точно тупиковая ветка. ИМХО не пишу специально - потому что в полной мертворожденности технологии уверен на 99.9%

← →
wisekaa © (2004-12-06 15:45) [62]

> [46] Суслик © (06.12.04 14:56)

Есть, но скомпилить нет возможности из-за отсутствия портированных компонент.

← →
Суслик © (2004-12-06 15:46) [63]

> интересная, типа чтобы голова не болела как объекты сохранять
> в БД, persistent layer. Но вот как оно будет работать, особенно
> на больших объемах.

На больших и реляционки работают так себе :)))
И вообще, что считать большими объемами?
Хранение данных для поисковых серверов интернера? Так это и реляционка с трудом прокачает.
Хранение 30 тыс бизнес объектов? Так для этого и скорости особе не надо.
В общем все это субъективно. Скорее успех eco будет зависеть от всеобщей поддержки и со стороны пользователей и со стороны конкурентов.

← →
by © (2004-12-06 15:49) [64]

Sergey_Masloff (06.12.04 15:45) [61]
Получается что любой persistent layer или OR mapping основанные на сопоставлении полей таблиц и полей объектов обресчены на неудачу и забвение? Или только конкретная реализация ввиде Bold или ECO?

← →
by © (2004-12-06 15:52) [65]

Суслик © (06.12.04 15:46) [63]
Большие для меня - это когда мне нужно для 3 000 000 записей за месяц сделать расчет по разным тарифным планам. И если я эту кучу буду вкачивать в объекты, то никаких ресурсов не хватит. Хотя если по одному, вкачали, обработали, записали, очистили, то будет жить. Вот только позволит ли так поступить тот же ECO.

← →
Sergey_Masloff (2004-12-06 15:52) [66]

Суслик © (06.12.04 15:43) [59]
>Ты слышал, что С. Орлик говорил недели две назад (можешь >поиском поискать)?
>"Life time delphi 6 кончился."
Слышал даже своими ушами а не читал. И что с того? Наш основной проект на Delphi 5 (а начинался на Delphi 2), прекрасно продолжает дописываться, ничего нужного начиная с 5 Delphi не добавилось - так чего нервничать. Да лайфтайм закончился - что с того? Что новую купить нельзя? Отлично как только мне понадобится новая лицензия я куплю последнюю версию. Но не до тех пор.
У нас куплены и 6, и 7 и 8-я Delphi, если с 6 и 7 я еще внимательно разбирался в нововведениях и для интереса портировал проект (не боевую версию) то теперь с меня хватит.
Да и 2 среды в одной как я уже спорил с кем-то это не фича а лишние проблемы.
Я так думаю ;-)

← →
DiamondShark © (2004-12-06 15:53) [67]

> iZEN © (06.12.04 15:24) [54]

> А как же совместимость?! .Net - это теперь база для Delphi.

Чего с чем совместимость?
Дельфи с НЕТ нормально совместились.

> Как сказал один из сотрудников Microsoft, в том, что разработчики
> вынуждены обрабатывать исключения, больше вреда, чем пользы.

Совершенно верно сказал.

> Иначе вы вынуждены читать исходный код вызываемого метода,
> чтобы узнать, какие исключения могут быть возбуждены.

А меня совершенно не интересует, какие исключения могут быть возбуждены.
Или интересуют не все.
Или интересуют только некоторые классы.

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

Т.о., обязательное описание исключений -- фича совершенно лишняя: компилятор и программирование усложняет, а никаких реальных задач не решает.

← →
Sergey_Masloff (2004-12-06 15:56) [68]

by © (06.12.04 15:49) [64]
>Получается что любой persistent layer или OR mapping
Ну это слишком сильное утверждение ;-)
Но их есть полно, много лет эта тема муссируется а "выхлопа" - ноль. Все это красиво работает в маленьких тестовых примерах (где оно не нужно) и ИМХО совсем не работает когда приходится копнуть подальше.
Я сам буквально "болел" ORM но что-то как показала практика особых преимуществ подход не имеет. Да, кое-что удобнее, кое-что - совсем неудобно вобщем не серебряная пуля это точно, а может и похуже ;-)

← →
DiamondShark © (2004-12-06 15:58) [69]

> На фига хранимые процедуры и триггеры, можно ж все написать
> дельфовым кодом.

Для БД-серверов красивых RAD-IDE нету, SQL ручками пейсать приходится.
А це нынче не модно.
;-)

← →
Sergey_Masloff (2004-12-06 15:59) [70]

DiamondShark © (06.12.04 15:53) [67]
>Т.о., обязательное описание исключений -- фича совершенно >лишняя: компилятор и программирование усложняет, а никаких >реальных задач не решает.
"Да он мог бы прямо на митингах деньги зарабатывать!" (с) Шариков. Нет, кроме шутки, по-хорошему завидую твоему умению сжато и точно формулировать. По сути согласен но мне так кратно не сказать ;-)

С уважением

← →
DiamondShark © (2004-12-06 16:01) [71]

> by © (06.12.04 15:52) [65]

3000000 записей для хорошего SQL-сервера -- не объём.
А для любой ОО-нашлёпки -- смерть.

Долой третий layer и пятое колесо!

← →
by © (2004-12-06 16:08) [72]

Sergey_Masloff (06.12.04 15:56) [68]
Я сейчас начитавшишь книжек усиленно копал в этом направлении. Но (ИМХО) уже вижу что для языков/IDE (Delphi и .Net) в которых ярко выражена концепция DataSet и есть куча методов работы с ним, в том числе и DBAware компоненты, лучшим методом будет будет модель таблицы с шлюзами к реальным таблицам БД. И нечего на все это натягивать объекты. Главное развязать визуальное отображение (форму) и логику.
Сорри за офтопик.

← →
Суслик © (2004-12-06 16:08) [73]

> [65] by © (06.12.04 15:52)

Какие eco, когда речь идет про 3 млн?
Думаю тут однозначно реляционка или еще что.

> [68] Sergey_Masloff (06.12.04 15:56)

> > На фига хранимые процедуры и триггеры, можно ж все написать дельфовым кодом.

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

Да, мы страдаем от потерь скорости. Этого не отнять. Но пока об архитектурном решении ни разу не пожалели.

> [71] DiamondShark © (06.12.04 16:01)
>
> Долой третий layer и пятое колесо!

Да зраствуют собственные сервера!

← →
Суслик © (2004-12-06 16:17) [74]

> [71] DiamondShark © (06.12.04 16:01)
> 3000000 записей для хорошего SQL-сервера -- не объём.
> А для любой ОО-нашлёпки -- смерть.

Хотелось бы с этим не согласится.

Я полагаю, что все зависит от подхода и задач. С точки зрения построения отчетов я полагаю, что sql лучше всего. С точки зрения insert\update\delete, то с твоим утверждением не могу до конца согласится. Важно понимать интенсивность таких операций.

Мы комбинируем два подхода. Пока проблем нет.

← →
Sergey_Masloff (2004-12-06 16:19) [75]

Суслик © (06.12.04 16:08) [73]
>Позволь заметить, что все зависит от задачи. В том числе и от >предполагаемых объемов информации.
Согласен

>При этом имеется в активе приемы ООП. Полиформизм, в частности, >в некоторых задачах имеет свой смысл.
И PL/SOL и T/SQL наверняка позволяют сделать то же самое. Пусть немного по-другому.

>Я бы посмотрел, как на sql сервере написали скрипт >поддерживающих логику нашего счета-фактуры
Да написали бы. Была б логика а реализовать ее хоть на счетах можно. У нас серверного кода раза в 2 больше дельфийского (а дельфийского сравнимо с тем что у тебя, не 2 млн. конечно но в рапйоне 1 точно). И ничего - и читается нормально, и поддерживается ИМХО проще дельфийского кода, и между платформами переносится совершенно прозрачно, вобщем плюсы перечислять пальцев не хватит. ;-)

С уважением

← →
Суслик © (2004-12-06 16:23) [76]

> [75] Sergey_Masloff (06.12.04 16:19)

> вобщем плюсы перечислять пальцев не хватит. ;-)

Самый главный плюс, это ты, скорее всего, sql:

1) либо знаешь лучше всего
2) либо начал изучать раньше и больше любишь
3) либо пришел в середине проекта, когда архитектура была ясна.

Может еще что-то...

С уважением.

← →
by © (2004-12-06 16:25) [77]

Суслик © (06.12.04 16:17) [74]
Просто получается что прийдется писать свой ORM, под свои задачи. Готовые без ограничений использовать трудно.

← →
Суслик © (2004-12-06 16:27) [78]

> Готовые без ограничений использовать трудно.

я уверен, что невозможно :((

Потому и пользуюсь своим.

← →
Sandman25 © (2004-12-06 16:31) [79]

[76] Суслик © (06.12.04 16:23)

Не надо бояться SQL, на самом деле он проще Delphi language.

← →
by © (2004-12-06 16:31) [80]

Суслик © (06.12.04 16:27) [78]
А свой ORM это много человеко-часов ((
И не факт что будет как надо. Фаулер рекомендует покупать )))

← →
Суслик © (2004-12-06 16:33) [81]

> [75] Sergey_Masloff (06.12.04 16:19)
> Да написали бы. Была б логика а реализовать ее хоть на счетах
> можно.

Как мне кажется разрабатывать в рамках эволюционного подхода все-таки проще в рамках языка, типа дельфи, ++ и пр, а не в рамках процедурного языка, коим, например, являтется T/SQL.
Рефакторинг проще делается в языках с компилятором. Многие моменты поправит за тебя компилятор, просто когда не сможет скомпилить как-нибудь конструктцию. В T/SQL все-таки сложнее.

← →
by © (2004-12-06 16:34) [82]

Sandman25 © (06.12.04 16:31) [79]
Та не боится его никто. Просто рекомендации лучших собаководов (Фаулер и иже с ними) говорят что объекты это лучшее решение, а если вас угораздило работать с БД, то используйте ORM. При этом навороченные СУБД получаются в роли бедных родственников, но зато переносимость с платформы на платформу высокая.

← →
DiamondShark © (2004-12-06 16:35) [83]

> Я бы посмотрел, как на sql сервере написали скрипт поддерживающих
> логику нашего счета-фактуры.

Легко.

← →
Суслик © (2004-12-06 16:36) [84]

> [79] Sandman25 © (06.12.04 16:31)

Я его не боюсь - я регулярно пишу отчеты.
Он проще, кончено, если ты знаешь особенности оптимизатора. Меня он задалбывает иногда. То план выберет не тот, то еще чего.

> [80] by © (06.12.04 16:31)

Да я уже понял, что ты Фаулера начитался. Хорошая книга.
А вообще все зависит от условий. У нас были условия писать такую штуку. 4 года работаем. Пока не пожалели. У кото-то могут быть другие условия. Задай мне писать новый проект месяца на 3-4, не в жизнь не связался бы со своими разработками - только штатные. Но для долгоиграющий проектов мне такой подход нравится вполне.

← →
DiamondShark © (2004-12-06 16:39) [85]

> не в рамках процедурного языка, коим, например, являтется
> T/SQL.

А я, несчастный, всю жизнь его декларативным считал...

← →
Sergey_Masloff (2004-12-06 16:40) [86]

by © (06.12.04 16:34) [82]
>При этом навороченные СУБД получаются в роли бедных >родственников,
;-)
>но зато переносимость с платформы на платформу высокая.
Это легенды.

Как хорошо сказал Т.Кайт - в конце концов реляционные СУБД это единственное что осталось неизменным в быстроразвивающемся мире IT в последние 25 лет и позиций не теряет. Основой чему является отличная математическая проработка технологиии и отлаженные за десятилетия механизмы реализации. Так что думайте сами решайте сами.

Если есть возможность комбинировать - можно комбинировать. Если думать о сосредоточении в одном месте логики - я за СУБД.

Хотя еще раз следует уточнить - "Определяет задача" (с) Суслик

← →
Danilka © (2004-12-06 16:41) [87]

[81] Суслик © (06.12.04 16:33)
> Многие моменты поправит за тебя компилятор, просто когда
> не сможет скомпилить как-нибудь конструктцию. В T/SQL все-таки
> сложнее.

PL/SQL с компилятором. Все ошибки сразу показывает. :))
Для T/SQL, говорят, неплохой отладчик ХП есть, правда сам с ним не пробовал работать, но, говорят, очень удобный.

← →
Суслик © (2004-12-06 16:42) [88]

> [83] DiamondShark © (06.12.04 16:35)
> Легко.

Если описание будет.

А если нужно придумать с заведо известной необходимостью неоднократного рефакторинга? Итерации, эволюция...

Не сомневаюсь, что на это можно ответить так: ну типа, батенька, найми проектировщика и все будет ок, он тебе выдаст описание и сразу в sql. Не спорю, но я таких проектировщиков не знаю.

Поэтому, либо неоднократный рефакторинг и эволюция развития, либо ноль.

Я не спорю, что на sql можно написать что угодно (в рамках разумного). Но переработка, повторное использование кода и пр. в нем сложнее. Будешь спорить?

← →
by © (2004-12-06 16:43) [89]

Суслик © (06.12.04 16:36) [84]
Да, если проект на длительное время разработки, то ориентироваться на что-то чужое стремно. Конечно если есть специалисты которые могут реализовать свое.

← →
Суслик © (2004-12-06 16:43) [90]

> [85] DiamondShark © (06.12.04 16:39)
>
> А я, несчастный, всю жизнь его декларативным считал...

ладно, ладно - не заводись :)
Я же не столько книжек прочел :)
За информацию спасибо.

← →
Суслик © (2004-12-06 16:46) [91]

Чтобы не скатываться в оффтоп вопрос по сабжу:

видел ли кто нормальные (или любые) книги по delphi 2005.

← →
Sandman25 © (2004-12-06 16:47) [92]

[82] by © (06.12.04 16:34)

Фаулер и иже с ними провозгласили, что если вас заботит быстрота кода, то экстремальное программирование не для вас. Основная задача - упрощение разработки, упрощение для человека. Таким образом большинство приложений, работающих с большими объемами данных (подавляющее большинство приложений БД) и с критичными требованиями к скорости, требуют другого подхода.
Реализовывать в объектах то же, что выполняется в хранимой процкедуре на 1000 строк, я бы никому не советовал.

← →
DiamondShark © (2004-12-06 16:48) [93]

> Суслик © (06.12.04 16:17) [74]
>
> > [71] DiamondShark © (06.12.04 16:01)
> > 3000000 записей для хорошего SQL-сервера -- не объём.
> > А для любой ОО-нашлёпки -- смерть.
>
>
> Хотелось бы с этим не согласится.
>
> Я полагаю, что все зависит от подхода и задач. С точки зрения
> построения отчетов я полагаю, что sql лучше всего. С точки
> зрения insert\update\delete, то с твоим утверждением не
> могу до конца согласится. Важно понимать интенсивность таких
> операций.
>
> Мы комбинируем два подхода. Пока проблем нет.

Этокакэто?

Я говорю вообще о манируляции данными, представленными в реляционной модели.
Что тут комбинировать? Комбинируй, не комбинируй, а схема всегда останется одной: Реляционная модель -> нашлёпка -> другая модель -> манипуляция -> нашлёпка -> реляционная модель.

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

← →
Суслик © (2004-12-06 16:53) [94]

> [93] DiamondShark © (06.12.04 16:48)

> Этокакэто?

Сторона БД (ms sql server)
1. Есть реляционка. Опустим с точки зрения простоты структуру.
2. Есть метаданные на сервере.
3. Есть часть mapper на сервере.
4. Есть интрументы управления блокировками (оптимистическими и пессимистическими). Они доступны объектоной модели.

Сторона толстого клиента
1. Есть метаданные на клиенте
2. Есть mapper на клиенте. Его можно так назвать - доmapper, т.е. доделывает то, что не доделал mapper на сервере.
3. Есть объектная модель с логикой.
4. Интерфейс.

Это один подход. Тут в регулярной работе я не сталкиваюсь с sql.

С точки зрения отчетов обращение к sql есть. Именно на нем пишутся все запросы.

Это я имел в виду под комбинацией: для транзакций без sql, для отчетов - sql.

← →
by © (2004-12-06 16:55) [95]

Sandman25 © (06.12.04 16:47) [92]
С таким определением полностью согласен. Наверное если скорость не на первом месте, тогда программирование через модели - очень хороший способ.

← →
DiamondShark © (2004-12-06 17:02) [96]

> Суслик © (06.12.04 16:42) [88]
>
> > [83] DiamondShark © (06.12.04 16:35)
> > Легко.
>
>
> Если описание будет.

А без описания ты ничего не реализуешь.
Какого угодно описания, даже самого общего и обтекаемого.

> А если нужно придумать с заведо известной необходимостью
> неоднократного рефакторинга? Итерации, эволюция...

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

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

> Поэтому, либо неоднократный рефакторинг и эволюция развития,
> либо ноль.

А у меня и был рефакторинг. Только им занимался уже не я и не на Дельфи/SQL, а настройщик системы/прикладной постановщик на языке описания своей предметной области.

← →
DiamondShark © (2004-12-06 17:07) [97]

> Суслик © (06.12.04 16:53) [94]

А, ну понял.

Это как раз то, про что говорил Сергей Маслов: сервер используется как хранилище.

Обидно. Зачем здесь MSSQL с его мощнейшими возможностями манипуляции данными, если они на 99% не задействованы?

Выкинутые на ветер деньги...

← →
Суслик © (2004-12-06 17:08) [98]

> DiamondShark © (06.12.04 17:02) [96]

Сложно спорить. Думаю, что мерилом эффективности должно служить то, сколько времени продукт используется успешно. У меня и у тебя (судя по всему) с этим все в порядке.

← →
Суслик © (2004-12-06 17:11) [99]

> DiamondShark © (06.12.04 17:07) [97]

> Это как раз то, про что говорил Сергей Маслов: сервер используется
> как хранилище.

в общем-то да, ты прав.

> Обидно. Зачем здесь MSSQL с его мощнейшими возможностями
> манипуляции данными, если они на 99% не задействованы?

Как говорили умные люди, не упускайте возможность юзать манагер системных транзаций. Для этого и юзаем.

К тому же запросы - все отчетв в нем.

← →
DiamondShark © (2004-12-06 17:33) [100]

> Суслик © (06.12.04 17:08) [98]
> Сложно спорить. Думаю, что мерилом эффективности должно
> служить то, сколько времени продукт используется успешно.

Я категорически против такого мерила. По общефилософским соображениям ;)

Хотя, не жалуюсь. Используется. И что меня больше всего радует -- используется без меня.

> Суслик © (06.12.04 17:11) [99]
> Как говорили умные люди, не упускайте возможность юзать
> манагер системных транзаций. Для этого и юзаем.

Да при чём тут манагер транзакций!
А, ладно...

← →
DiamondShark © (2004-12-06 17:36) [101]

Вспомнилось:

Введением дополнительного слоя можно решить любую проблему.
Кроме проблемы большого количества слоёв.

← →
Суслик © (2004-12-06 17:43) [102]

> [100] DiamondShark © (06.12.04 17:33)

> Да при чём тут манагер транзакций!
> А, ладно...

Как при чем? Ты мне предлагаешь его самому написать? :) Я против...
Есть сервер, почему бы его не юзать...

> Я категорически против такого мерила.

Я тоже был раньше против. И тоже по тем же причинам. Но вырос :))

← →
DiamondShark © (2004-12-06 17:54) [103]

> Есть сервер, почему бы его не юзать...

Ну да. Для манипуляции данными. Без промежуточных преобразований.

> Но вырос :))

Ню-ню ;)

← →
Суслик © (2004-12-06 18:01) [104]

> [103] DiamondShark © (06.12.04 17:54)

Ладно, опустим общие слова, которые ясны любому разработчику баз данные - все на вервере, sql рулит и пр. Можно конкретней?

Есть потребность в интерфейсном вводе документа, который обладает 1-3 уровневыми master-detail с нефиговой логикой зависимостей полей. Грубо говоря - тут поравил, пересчитался весь документ (полей так 200). Там поправил - еще пара сотен. Т. е. есть потребность в интерактивном вводе информации с быстрым откликом системы. Алогоритмы пересчета полей достаточно заумные.

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

← →
Суслик © (2004-12-06 18:45) [105]

Вопрос про книги все-таки остается - видел ли кто-нибудь достойные книги по дельфи 2005?

← →
vuk © (2004-12-06 18:46) [106]

to Суслик © (06.12.04 18:01) [104]:
>Как бы ты реализовал данную возможность?
Пересчет на сервере. У него больше информации о текущем состоянии системы в целом.

← →
DiamondShark © (2004-12-06 18:51) [107]

> Суслик © (06.12.04 18:01) [104]

Такую вещь -- на клиенте.

Но я бы ещё двадцать раз подумал, стоит ли тут применять метафору документа в полном объёме.

← →
Суслик © (2004-12-06 19:00) [108]

> [106] vuk © (06.12.04 18:46)
> Пересчет на сервере. У него больше информации о текущем
> состоянии системы в целом.

Я не сомневался, что ответ будет таков.

Т.к. персчет на сервере, значит есть изменение серверных данных, значит должна быть транзакция. Какой уровень изоляции? Полагаю, что нехилый - ближе к serizable - обновление долгосрочное, фантомы и nonrepetable read здесь не нужны.

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

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

Можно использовать временные таблицы, табличные переменные и пр. Т.е. не постить в базу. Если так, то зачем тогда вообще это делать на сервере, если пересчитать объекты до их сохранения можно с равным успехом на клиенте? При том, что в момент сохранения (т.е. краткосрочно) действует пессимистическая блокировка с обязательной проверкой на уровне клиента и на уровне сервера.

← →
Суслик © (2004-12-06 19:03) [109]

> [107] DiamondShark © (06.12.04 18:51)
> Но я бы ещё двадцать раз подумал, стоит ли тут применять
> метафору документа в полном объёме.

На заре системы данный факт я усиленно оспаривал. Не удалось :((
Я бы тоже реализовывал несколько иначе. Но таково было требование - быстрый отклик системы при вводе замороченного документа.

← →
DiamondShark © (2004-12-06 19:04) [110]

> Суслик © (06.12.04 19:00) [108]

Где тебе там долгосрочные транзакции померещились?

← →
Суслик © (2004-12-06 19:05) [111]

Я, может быть поторопился, с таким высоким уровнем изоляции :)))
Но транзакция в любом случае нужна. А вот какой уровень использовать это нужно подумать.

← →
Суслик © (2004-12-06 19:08) [112]

> [110] DiamondShark © (06.12.04 19:04)

> Где тебе там долгосрочные транзакции померещились?

Я вижу хорошо. Спасибо за заботу о моем здоровье :)

Так. Пользователь решил отредактировать документ. Редактировал, редактировал и передумал. Т.е. нужон откат.
Что будешь делать в этом случае? Полагаю либо транзакция, либо временный сброс данных в промежуточные таблицы с сохранением их в основных таблицах в момент подтверждения пользователем сохранения. Есть другой путь?
Во втором случае транзакции может и не нужны. Но это некий наворот, в котором лично у меня нет опыта. Возможно, что это станратный путь решения подобных задач. Я просто не знаю.

Просвети.

← →
DiamondShark © (2004-12-06 19:09) [113]

> Если так, то зачем тогда вообще это делать на сервере, если
> пересчитать объекты до их сохранения можно с равным успехом
> на клиенте?

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

← →
Суслик © (2004-12-06 19:13) [114]

> [113] DiamondShark © (06.12.04 19:09)

> Часть из них может достаточно активно меняться.

Что кроется под этой фразой? В процессе пересчета данного документа? Если да, то активное изменение данных можно седалть и при сохранении документа: в процессе рассчета документа такое на фиг не нужно. Пока пользователь не решил сохранить документ - никаких изменений. Да, согласен, что активное изменение связных данных при сохранении можно поручить и процедуре. А можно и не поручать - это не догма.

← →
DiamondShark © (2004-12-06 19:18) [115]

> Суслик © (06.12.04 19:13) [114]
>
> > [113] DiamondShark © (06.12.04 19:09)
>
>
> > Часть из них может достаточно активно меняться.
>
> Что кроется под этой фразой?

Например, за время редактирования документа может поменяться справочник. Или остатки на складе.

← →
vuk © (2004-12-06 19:22) [116]

to Суслик © (06.12.04 19:00) [108]:
>Ты думаешь есть смысл в том, чтобы держать долгосрочне
>транзации такого уровня?
Никто вообще не собирается держать какие-либо долгосрочные транзакции. Транзакция будет, но только на время изменения данных. Эксклюзивность доступа реализуется блокировками ресурсов на уровне приложения. Если же нужен откат, то тут, на мой взгляд, стоит делать историю изменений с возможностью отката по истории.

← →
Суслик © (2004-12-06 19:25) [117]

> [115] DiamondShark © (06.12.04 19:18)

> Например, за время редактирования документа может поменяться
> справочник. Или остатки на складе.

И в чем проблема?
Ну может. На то и есть оптимистическая блокировка. Пусть меняются. При сохранении факт изменения справочника отловится. И в зависимости от контекста будут выполнены те или иные действия.

Т.е. допустимость независимых изменений с контролем состоятельности данных в момент сохранения посредством определенных блокировок гарантирует корректность данных.

Да, это медленнее. Зато логика в одном месте.

> [116] vuk © (06.12.04 19:22)

Очень хорошо, что не собираетесь делать долгосрочные транзации. Я и такое видал :)))

> Если же нужен откат, то тут, на мой взгляд, стоит делать
> историю изменений с возможностью отката по истории.

Без проблем, но это надо делать. Почему бы не применить другой подход. О редактировании сервер ничего не знает. Вот только сохранение (короткий момент) подвергается опеределенным правилам, которые гарантируют корректность. Чем плохо?

← →
vuk © (2004-12-06 19:27) [118]

to Суслик © (06.12.04 19:25) [117]:
>Чем плохо?
Трудноотслеживаемостью множественных ошибок.

← →
Суслик © (2004-12-06 19:29) [119]

> [118] vuk © (06.12.04 19:27)

> Трудноотслеживаемостью множественных ошибок.

Кто отслеживает? Кто совершает?

Ничего не понятно :))

Если ты (образно говоря) совершаешь ошики, они всегда трудноотслеживаемы. И не важно где - на сервере, на клиенте.

← →
vuk © (2004-12-06 19:33) [120]

to Суслик © (06.12.04 19:29) [119]:
>Кто отслеживает? Кто совершает?
Пусть в документе 10 позиций. Пока мы редактировали их на клиенте, все было нормально, но когда решили сохранить изменения,
3 из них не прошли проверку по каким-то условиям. Что делать?

← →
DiamondShark © (2004-12-06 19:33) [121]

> При сохранении факт изменения справочника отловится. И в
> зависимости от контекста будут выполнены те или иные действия.

И в чём тогда смысл навороченной валидации на клиенте? Если на сервер всё равно могут быть отправлены невалидные данные (причём в большом объёме).

Я ж говорю: надо двадцать раз думать, прежде чем применять метафору документа.

← →
wisekaa © (2004-12-06 19:38) [122]

А как быть с наложением ввода?
Если мы говорим, что документ сложный с кучей зависимостей, то есть вероятность, что одна из составляющих этого документа может быть отредактирована другим пользователем.
Т.Е. Один открыл на редактирование документ, другой изменяет его составляющую, у кого в этом случае будет правильный вариант?

Составляющая изменена, а пересчет пойдет со старыми данными?
Затреться ли правка составляющей документа, при сохранении всего документа?

← →
wisekaa © (2004-12-06 19:39) [123]

Пока набирал, мой вопрос прозвучал, правда в другом контексте.

← →
DiamondShark © (2004-12-06 19:44) [124]

> wisekaa © (06.12.04 19:38) [122]

Это решается на уровне прикладных правил, а не серверными средствами.

← →
Суслик © (2004-12-06 19:47) [125]

> [120] vuk © (06.12.04 19:33)
> Пусть в документе 10 позиций. Пока мы редактировали их на
> клиенте, все было нормально, но когда решили сохранить изменения,
> 3 из них не прошли проверку по каким-то условиям. Что делать?

Зависит от ситуации и от задачи.
Если постановка задачи такова, что в этом случае надо делать откат и пользователь должен заново перевоодить данные, то:
1. Либо проектировщик думает, что может быть в этом случае стоит применить пессимистическую блокировку данных.
2. Скорее всего п. 1 недопустим (за редким исключением). В этом случае можно сделать именно так - отворот, поворот - вводи заново (вернее, оредактируй ввод). Опыть показывает, что такие колизии происходят редко - все что может случиться плохого - пользователь подумает лишний раз.

> [121] DiamondShark © (06.12.04 19:33)

> И в чём тогда смысл навороченной валидации на клиенте? Если
> на сервер всё равно могут быть отправлены невалидные данные
> (причём в большом объёме).

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

В итоге веротяность непрохождения проверок на сервере очень мала. В любом случае корректность данных будет отслежена.

> [122] wisekaa © (06.12.04 19:38)

> А как быть с наложением ввода?

В основном пользователю предлагается осознанной сделать правки в документ. Но это только в том случае, когда связное редактирование критично.

← →
wisekaa © (2004-12-06 19:50) [126]

>> [124] DiamondShark © (06.12.04 19:44)
А я и не говорю о серверной реализации.

<OffTopic>
Суслик, фотки когда ожидать?
</OffTopic>

← →
vuk © (2004-12-06 19:50) [127]

to DiamondShark © (06.12.04 19:44) [124]:
>Это решается на уровне прикладных правил, а не серверными
>средствами.
Ну... Можно и серверными. В MSSQL блокировка "документов" замечательно делается при помощи блокировок уровня приложения.

← →
Суслик © (2004-12-06 19:51) [128]

<alsoOffTopic>
когда фотик на работу принесу.
Постараюсь завтра.
</alsoOffTopic>

← →
vuk © (2004-12-06 19:58) [129]

to Суслик © (06.12.04 19:47) [125]:
>В этом случае можно сделать именно так - отворот, поворот -
>вводи заново (вернее, оредактируй ввод).
При этом, скорее всего, получится узнать только о первой ошибке, а не об остальных двух оставшихся. Веселуха будет, если после правки строки номер 2 перестанет проходить проверку строка номер 5, которая раньше ее проходила... И так - до тех пор, пока все условия не выполнятся?

>Опыть показывает, что такие колизии происходят редко - все что
>может случиться плохого - пользователь подумает лишний раз.
Пользователь, он скорее всего думать не будет, а скажет, мол, что это за софт, который вводить данные дает, а сохранить их не может...

← →
DiamondShark © (2004-12-06 20:01) [130]

> vuk © (06.12.04 19:50) [127]
> Ну... Можно и серверными. В MSSQL блокировка "документов"
> замечательно делается при помощи блокировок уровня приложения.

Што?! На всё время редактирования?

← →
DiamondShark © (2004-12-06 20:03) [131]

Мда... Дельфи 2005 нежно похерили ;)
Клиент-сервер архитектура намного интереснее.
;-)

← →
Суслик © (2004-12-06 20:05) [132]

> [129] vuk © (06.12.04 19:58)

> Пользователь, он скорее всего думать не будет, а скажет,
> мол, что это за софт, который вводить данные дает, а сохранить
> их не может...

Понятие оптимистическая блокировка думаю тебе многое говорит. Как думаешь, почему такая фича существует? Думаю не для того, чтобы пользователи такое говорили. А?

← →
vuk © (2004-12-06 20:05) [133]

to DiamondShark © (06.12.04 20:01) [130]:
>Што?! На всё время редактирования?
А што? :o) Открыл "документ" - вызвал sp_getapplock, вышел - sp_releaseapplock. Проверять можно хоть на клиенте хоть на сервере. В случае, если клиент отвалился, блокировка уходит.

← →
}|{yk © (2004-12-06 20:05) [134]

Почему иногда лучше написать промежуточный сервер? А как вы на sql реализуете формулы (причем некоторые могут занимать несколько страниц - в финучёте это не редкость)

← →
Суслик © (2004-12-06 20:10) [135]

> [131] DiamondShark © (06.12.04 20:03)
> Мда... Дельфи 2005 нежно похерили ;)
> Клиент-сервер архитектура намного интереснее.
> ;-)

Я тоже заметил.
Сам-то - просил не флеймить, а развел тут :)))

Клиент-сервер - это вечно! А дельфи (мн. число) приходят и уходят )

← →
iZEN © (2004-12-06 23:46) [136]

А как насчёт вебсервисов?
Что, заглохло совсем?

← →
Petr V. Abramov © (2004-12-07 02:18) [137]

> Суслик © (06.12.04 20:10)
> ... документа, который обладает 1-3 уровневыми master-detail с
> нефиговой логикой зависимостей полей. Грубо говоря - тут
> поравил, пересчитался весь документ (полей так 200).
Прям квадратный двухсотчлен какой-то :) И пользователь все эти 200 полей смотрит??? И они на экран помещаются?

← →
KSergey © (2004-12-07 08:14) [138]

> [59] Суслик © (06.12.04 15:43)
> Ты слышал, что С. Орлик говорил недели две назад (можешь
> поиском поискать)?
>
> "Life time delphi 6 кончился."

А можно цитатку точнее или может не сочтете за труд ссылочку дать, а? А то что-то не выходит у меня найти...

PS
Зато с удивлением обнаружил такую вот ветку на данном форуме от 2003 года, поразительно, но не ушедшую в архив:

http://delphimaster.net/view/10-1070985161/

← →
Sergey_Masloff (2004-12-07 09:13) [139]

}|{yk © (06.12.04 20:05) [134]
>А как вы на sql реализуете формулы (причем некоторые могут >занимать несколько страниц - в финучёте это не редкость)
Ой да ладно. В страховании расчет текущих резервов и покруче формулы дает. И ничего - пишется как-то.
Как уже сказано - если есть методика то написать ее можно на чем угодно (а на внутреннем языке SQL сервера даже легче потому что доступ к данным быстрее и прозрачнее). Если методики нет то написать нельзя ни на чем.

← →
Суслик © (2004-12-07 10:12) [140]

> [138] KSergey © (07.12.04 08:14)

Она вроде в архив уже ушла - месяц назад была

> [137] Petr V. Abramov © (07.12.04 02:18)

Зачем влезать? Форма интерактивная. Все сразу не видно.

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

Пользователь жмет в списке оплаты - получает список закрытий (это уже master-detail второго уровня, но бывают и третьего).

Форма сильно интерактивная. Есть разные режимы автоматического распределения. Есть ручной режим. Смена распределения может привести к перерасчету нескольких сотен полей. При этом это есть нормально - зачастую решаются задачи метода деления пополам (условно, а не буквально) - пользователь интерактивно распределяет оплату наиболее правильным образом (заранее правильного способа никто не знает - на то он и бухучет :)))

Прикажешь каждый раз это делать на сервере? Он же загнется.

Все легко и просто.

← →
Суслик © (2004-12-07 10:28) [141]

> [143] Sergey_Masloff (07.12.04 09:13)
>Если методики нет то написать нельзя ни на чем.

Не слова, а золото :))

← →
Andryk © (2004-12-07 10:34) [142]

Гм как вы, однако, отошли от темы, и переключились на различия в архитектуре. Ну, тогда выскажусь и я по этому поводу. Я тоже долгое время был противником использования СУБД просто как хранилища данных. Но в последнее время я пересмотрел свою позицию. Несколько причин, по которым все же следует строить системы по трехзвенной архитектуре (в основном это применимо к J2EE):
1. Независимость от СУБД. При наличии драйверов к БД вас не заботит диалект SQL, на котором "говорит" БД. Это дает возможность легко поменять БД для конкретного заказчика, если есть у него деньги, то Oracle, нет денег или желания тратить деньги на дорогую СУБД, то можно на бесплатных версиях IB.
2. Бизнес слой пишется на одном языке, который не зависит от СУБД. Это опять же дает простой переход к любой БД, так, например, если бы кто-нибудь попробовал бы перенести клиент-серверную систему с Oracle на MsSql, да еще и поддержка у двух разных заказчиков. Думаю что это была бы не тривиальная задача, т.к. когда я работал в одной конторе, там было несколько заказчиков, а у одного стоял Oracle 7 версии у других Oracle 8 и у же были большие проблемы поддерживать системы.
Эти два пункта сильно удешевляют систему и, следовательно, привлекают больше клиентов.

Да существуют и минусы, например, вы не можете управлять транзакциями в БД как вам позволяет это делать клиент-серверная архитектура. Но думаю, что эти два пункта перевешивают эти минусы. ))))

Теперь по поводу ECO, ИМХО, это просто технология построения толстого клиента для клиент-серверной архитектуры, с возможностью легкого перехода на трехзвенную структуру, основанной, например на J2EE.

← →
Sergey_Masloff (2004-12-07 11:09) [143]

Andryk © (07.12.04 10:34) [142]
>1. Независимость от СУБД.
Это сказки. Объясню почему - если система может работать с разными СУБД то она работает с ними как с наименее функциональной из всего набора. Тот "учет специфики сервера" который декларируется некоторыми ORM это детский лепет.
Просто получается вы обкрадываете своих клиентов которые используют более мощные серверы СУБД так как их (немалые) деньги уплаченые за мощь сервера выбрасываются на ветер. Потому что в качестве простой свалки таблиц ORACLE ничуть не лучше (если не хуже) того же интербейса или mysql (последний даже точно лучше так как из-за примитивности транзакционной работы быстрее функционирует). Ведь так? ;-)
Но это я со своей колокольни. Тем более если у кого-то нашлись деньги на нашу систему то покупка Оракла, лицензий и железа будет для него мелочью ;-)))

← →
Суслик © (2004-12-07 11:17) [144]

> [143] Sergey_Masloff (07.12.04 11:09)

Почему не верите в независимость от субд?
В полном объеме и я в нее не верю. Но ведь это уровень провайдера (своего). Напиши штук 10 провайдеров по переводу своих метаданных в конкретный код конкретного сервера.

Мы пока живет только для ms sql. Но это дело одног-двух месяцев вынести все в отдельный класс, который полимоврфно бы использовался. Еще дело нескольких месяцев и несколькоих спецов конкретного сервера написать билдер запросов для oracle или еще для чего.

Конечно, руками писать оптимальнее. Я не спорю. Но определенную долю оптимизации можно и тут делать. Например в нашем построителе для join есть управление оптимизатором в виде merge или hash в зависимости от контекста использования.

← →
DiamondShark © (2004-12-07 11:20) [145]

> Тот "учет специфики сервера" который декларируется некоторыми
> ORM это детский лепет.

Нет, ну почему же...
С учётом специфики сервера можно сделать довольно эффективную надстройку. Вот только "независимость" сразу куда-то девается ;-)

← →
Суслик © (2004-12-07 11:32) [146]

> Нет, ну почему же...
> С учётом специфики сервера можно сделать довольно эффективную
> надстройку. Вот только "независимость" сразу куда-то девается
> ;-)

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

Да, нет универсальности в полном объеме. Но ведь и не любой сервер обязан поддерживать sql вобще. А почему скажете мне текстовый файл не подходит в качестве хринилища? :)) Напиши своего провайдера и дело с концом. Ползать будет, зато дешево :)

← →
Andryk © (2004-12-07 11:32) [147]

> Sergey_Masloff (07.12.04 11:09) [143]
> Andryk © (07.12.04 10:34) [142]
> >1. Независимость от СУБД.
> Это сказки. Объясню почему - если система может работать
> с разными СУБД то она работает с ними как с наименее функциональной
> из всего набора. Тот "учет специфики сервера" который декларируется
> некоторыми ORM это детский лепет.

Как вы думаете выборка значения по ключам это эфекитвный способ? Так вот J2EE обращается к к БД по ключам, старается конечно по первичным. Да конечно она не строит многоуровневые запросы, но это ей и не надо. Там также есть возможность написания своих собственных запросов, для обращения и изменения данных, но как только вы привязываетесь к конретной СУБД. Вы сразу сужаете круг потенциальных клиентов. А мощь СУБД можно использовать для построения отчетов.

← →
Суслик © (2004-12-07 11:33) [148]

> А мощь СУБД можно использовать для построения отчетов.

во и я тоже самое говорю.

Не фиг мешать отчеты и insert\update\delete. Разные вещи, имхо.

← →
euru © (2004-12-07 11:36) [149]

>Sergey_Masloff (07.12.04 11:09) [143]
>Это сказки.

А как же SAP?

← →
Sergey_Masloff (2004-12-07 11:45) [150]

euru © (07.12.04 11:36) [149]
>А как же SAP?
А никак. См. что я писал выше. В SAP РОВНО то же самое.

Суслик © (07.12.04 11:33) [148]
>Не фиг мешать отчеты и insert\update\delete.
Ага. Только есть системы в котором без отчета никакого update не бывает ;-)

← →
}|{yk © (2004-12-07 11:46) [151]

Независимость от СУБД это не сказки. Comshare MPC может использовать Oracle, MS SQL, ESBase и еще некоторые СУБД. И работает с вполне нормальной скоростью.

← →
Суслик © (2004-12-07 11:49) [152]

> [150] Sergey_Masloff (07.12.04 11:45)
> euru © (07.12.04 11:36) [149]

> Только есть системы в котором без отчета никакого update не бывает ;-)

А мое какое дело? У меня такая система? Вроде нет... Спасение утопающих, ну ты знаешь... :))

>Sergey_Masloff (07.12.04 11:45) [150]

А вы уверены, что если к свалке таблиц добавить свалку хранимых процедур, то производительность системы клиент/сервер увеличится?

← →
Sergey_Masloff (2004-12-07 12:11) [155]

euru © (07.12.04 12:01) [154]
>А вы уверены, что если к свалке таблиц добавить свалку хранимых >процедур, то производительность системы клиент/сервер >увеличится?
На 100%. Потому что доступ к обрабатываемым данным обеспечивается максимально эффективным способом. А ведь обработка данных - основная задача? Или и по этому вопросу возражения имеются? ;-)

}|{yk © (07.12.04 11:46) [151]
>может использовать Oracle, MS SQL, ESBase и еще некоторые СУБД. >И работает с вполне нормальной скоростью.
Я считаю нормальной только максимально возможную скорость. Ну вот такое мое ИМХО.
Кстати и активно пиарящаяся вами Comshare MPC правильность универсального подхода не особо доказывает. Да, есть такая система но во-первых бюджетирование не особо сложная для отображения в объектную модель область во-вторых там не особой многопользовательскости ни больших объемов данных и не требуется. Так что пример неудачный. Следующий ;-)

Следующий ;-)

Я!

Что париться из-за недопоставленной задачи: разные задачи, разные решения.

Где-то это важно

> Я считаю нормальной только максимально возможную скорость.
> Ну вот такое мое ИМХО.

где-то большую важность имеет гибкость и пр.

Зачем спорить...

> Sergey_Masloff (07.12.04 12:11) [155]
euru © (07.12.04 12:01) [154]
>>А вы уверены, что если к свалке таблиц добавить свалку
>> хранимых >процедур, то производительность системы
>> клиент/сервер >увеличится?

> На 100%.
пессимист :)

Как это ни особой многопозовательности? Питерская фирма КОРУС установила данную систему в (забыл как точно называется) российский аналог "Укртелекома". Данные поступают постоянно со всей России на центральный сервер. И объемы данных большие.

← →
Sergey_Masloff (2004-12-07 12:22) [159]

Суслик © (07.12.04 12:15) [156]
>Зачем спорить...
Экшн. Это раз. Ну и во вторых - раз есть спор значит есть мнения. Думаешь стал бы я спорить с тобой (сюда можно подставить и других) если бы твое мнение меня не интересовало?
Ну написал бы "да, правильно" и дело с концом. Ветка на 3 сообщения была б. А так вот как разрослось. Правда куда нам до украины но хоть что-то.

← →
Sergey_Masloff (2004-12-07 12:24) [160]

}|{yk © (07.12.04 12:19) [158]
>И объемы данных большие.
Ну откуда в бюджетировании большие данные? Не знаю. Ну ладно поверю пока на слово ;-)

> [159] Sergey_Masloff (07.12.04 12:22)

> Правда куда нам до украины но хоть что-то.

:))))
Предлагаю. Расскажи о своей системе:
1. О среднем количестве сущностей (максимальное, прирост в год)
2. О количетве пользователей.
3. О критическом времени запроса
4. О интенсивности обновления данных (добавления)

О себе:
Система бухучета купноотпотового превозчика с простой структурой данных и сложной логикой.
1. Максимально расчетное кол-во сущностей - до 3 млн. Т.к. система бухучета, то цикл годовой (потом в архив). Т.е. за год 3 млн не набираем.
2. До 20
3. Не оговаривается, но оперативные запросы (частовызываемые) - не более 20 сек. Есть по несколько десятков минут не из-за сложности, а из-за ошибок, но т.к. они редки - руки не доходят.
4. Самый критический случай - массоый ввод документо одним из пользователей (порядка 1-2 в сек, всего до 1000) при том, что остальная система должна ворочаться.

Достоинства, что логика реализуется в сриптовом языке толстого уровня. Язык оперирует в рамках определенных условий, которые гарантируют:
1. Целостность.
2. Атомарность транзаций.
3. и пр.
Более сложные вещи реализуем на дельфи.

Ну как это? А факт? План конечно занимает немного, а факт получается изо всевозможных учетных систем. Но обрабатывается (консолидируется) уже самой Comshare MPC.

Я читал о том что в .NET Framework 1.2 MS вводят поддержку ORM через свои ObjectSpaces.
http://www.rsdn.ru/article/dotnet/objectspaces.xml
Они видят в этом перспективу, но пока это в стадии разработки так как достаточно сложно.

to Sergey_Masloff:
>Или и по этому вопросу возражения имеются?
Я думаю, найдутся. Правда не я. :o) Просто у кого-то на первом плане эффективность разработки, а не эффективность функционирования. От этого и споры.

> [164] vuk © (07.12.04 12:30)

> Просто у кого-то на первом плане эффективность разработки

Ну и что здесь такого?
Не будет эффективной разработки - не будет ни эффективного функционирования, ни неэффективного функционирования. Логично?

>Sergey_Masloff (07.12.04 12:11) [155]
>На 100%. Потому что доступ к обрабатываемым данным
>обеспечивается максимально эффективным способом. А ведь
>обработка данных - основная задача? Или и по этому вопросу
>возражения имеются? ;-)

По вопросу? Имеются. Основная задача (точнее, одна из основных задач) - это эффективная обработка данных. :)

По утверждению тоже имеются. Вместо того чтобы просто выбрать данные и отправить их клиенту для дальнейшей обработки, СУБД будет тратить своё процессорное время на обработку этих данных, задерживая остальные запросы в очереди.

vuk © (07.12.04 12:30) [164]
Проблема действительно в приоритетах. Если приоритетна скорость вывода продукта на рынок, а не максимальная производительность, то конечно через ECO и прочие ORM можно быстрее набросать.
Тем более что производительность через объекты вполне может устроить.

> СУБД будет тратить своё процессорное время на обработку
> этих данных, задерживая остальные запросы в очереди.

Вот, золотые слова.
У меня половина зпросов на клиенте сделана. Смею вас заверить, что зная логику можно создать более оптимальный запрос, чем это делает серверный оптимизатор. Тебе не нужно собирать статистику: ты знаешь какая особенность данных и как их лучше обрабатывать. Merge, hash или loop. На это не тратится. Время.

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

to Суслик © (07.12.04 12:31) [165]:
>Не будет эффективной разработки - не будет ни эффективного
>функционирования, ни неэффективного функционирования.
Это из серии "Ну и что, что тормозит? Зато смотрите как круто мы код генерим!"? :o)

> [169] vuk © (07.12.04 12:39)

Иногда это важнее? Не находишь?

Да и торможение поняте относительное. Если люди могут делать работу, на которую тратили до нескольких дней, за 10 минут, то им по фигу 10 это минут, или 0.001 секунд.

> vuk © (07.12.04 12:30) [164]
> Просто у кого-то на первом плане эффективность разработки, а
> не эффективность функционирования. От этого и споры.
Насчет эффективности разработки тоже можно поспорить :) С тобой не буду :)

to Суслик © (07.12.04 12:35) [168]:
>Смею вас заверить, что зная логику можно создать более
>оптимальный запрос, чем это делает серверный оптимизатор.
И как это связано с используемой архитектурой? Кстати, иногда даже зная логику не получается эффективно написать не изучая планы запросов.

>Прикол в том, что 99 процентов времени тратится на анализ
>запроса, а не на выполнение.
О! А процедура анализируется и оптимизируется один раз. В MSSQL - при первом запуске.

> С тобой не буду :)

во-во, а я ввязался.

> О! А процедура анализируется и оптимизируется один раз.
> В MSSQL - при первом запуске.

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

> И как это связано с используемой архитектурой?

Не понятно? Можно не возлагать на сервак все обязанности. Именно в этом.

> Суслик © (07.12.04 12:46) [173]
> во-во, а я ввязался.
Да не, я-то имел в виду, что не с vuk © у меня предмет спора отсутсвует :)

>vuk © (07.12.04 12:45) [172]
>О! А процедура анализируется и оптимизируется один раз. В MSSQL - при первом запуске.

Всё-таки, как бы ни была оптимизирована процедура, на её выполнение всё равно понадобится некоторое время. И мы снова возвращаемся к [166].

Petr V. Abramov © (07.12.04 12:51) [175]
> Суслик © (07.12.04 12:46) [173]
> во-во, а я ввязался.
Да не, я-то имел в виду, что с vuk © у меня предмет спора отсутсвует :)

← →
Sergey_Masloff (2004-12-07 12:59) [181]

euru © (07.12.04 12:54) [177]
>Всё-таки, как бы ни была оптимизирована процедура, на её >выполнение всё равно понадобится некоторое время. И мы снова >возвращаемся к [166].
Если эта процедура для своей работы обращается к данным которых нет у клиента (а это обычно так и бывает - справочники там, тарифные таблицы - да мало ли что) то на дерганье сетевого стека уйдет на порядки больше времени.

Суслик © (07.12.04 12:29) [161]
> Предлагаю. Расскажи о своей системе:
....
> О себе:
....

Если вероятность конфликта за бух/складские остатки, свободные машины и т.п. низкая, это можно на 1С сделать (лет 5 назад нельзя было, техника была слабая). Если вероятность высокая - сразу забудешь про оптимистические блокировки и уберешь логику на сервер

← →
Sergey_Masloff (2004-12-07 13:07) [184]

Суслик ©
Я твой пост не замалчиваю. Но написать не могу - конфиденциально все :(
Примерно так:
1) На порядок больше у нас (кроме того на каждую сущность хранится история изменений но это я не считаю так как в работе не используется - только для разборов полетов)
2) По самым скромным оценкам на 2 порядка больше у нас
3) Так же. В смысле критично чтобы устраивало пользователя. С секундомером не меряем.
4) Работа по добавлению (и изменению) интенсивная - для всех пользователей наш софт основной инструмент, то есть скажем 50% рабочего времени они там манипулируют.
95% логики - сервер.

Вот вроде секретов не раскрыл но суть передал. Я к чему - работать можно, как практика показывает, ничто не следует воспринимать как догму ;-)

>Sergey_Masloff (07.12.04 12:59) [181]

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

← →
Sergey_Masloff (2004-12-07 13:20) [186]

euru © (07.12.04 13:15) [185]
Да знаю я что буферизуются. Итак имеем: На сервере приложений огромный массив неактуальных данных в памяти. На клиенте - на каждый чих необходимость лазить за данными на сервер приложений. На сервере имеем необходимость по второму разу контролировать потенциально недостоверные данные. Я праильно уловил суть? ;-)

>Sergey_Masloff (07.12.04 13:20) [186]
1. Для того чтобы буферизация была адекватна актуальности данных, имеется 3 стратегии буферизации: буферизация всей таблицы, буферизация по определённым ключевым полям и буферизация одной записи.
2. На клиенте вообще ничего происходит. Его задача передать серверу приложений запрос и отобразить результат. Все проблемы разруливает сервер приложений, и делает это он один раз.

> [184] Sergey_Masloff (07.12.04 13:07)

Ну раз такие объемы, то спорить не буду.
Как я говорил - всему свой инструмент.

> [182] Petr V. Abramov © (07.12.04 13:03)

У нас не только опт. блок. есть. Есть и пессимистические. Выбор - после оценки вероятности конфликтов.

← →
Sergey_Masloff (2004-12-07 14:03) [189]

euru © (07.12.04 13:56) [187]
>1. Для того чтобы буферизация была адекватна актуальности >данных, имеется 3 стратегии буферизации: буферизация всей >таблицы, буферизация по определённым ключевым полям и >буферизация одной записи.
Ну какая стратегия. Я считаю формулу тариф по совокупности условий хочу взять из справочника. Беря данные с сервера приложений никакая стратегия не гарантирует мне что данные те же что в БД. Или триггер в БД должен на каждый чих оповещать все сервера приложений. Что очень накладно видимо?

> Беря данные с сервера приложений никакая стратегия не гарантирует
> мне что данные те же что в БД.

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

← →
Sergey_Masloff (2004-12-07 14:09) [191]

Суслик © (07.12.04 13:59) [188]
>Ну раз такие объемы, то спорить не буду.
Ну и зря. Лучше спорить - когда для спора ищешь аргументы то можно и для себя многое по полочкам разложить. Я например пытался по "твоей" стратегии работать. Есть проектик но что-то то ли я недопроектировал то ли просто сала в голове не хватило. Вобщем-то работает оно работает но в поддержке тяжеловат вышел. Но в этом значительная часть моей вины так как по всем показателям как раз для такой модели задача подходила ;-)

> [189] Sergey_Masloff (07.12.04 14:03)

Если ты про билинг, а еще и МТС какой нить, то зачем вообще в этих спорах принимать участие (нисколько не призываю отказаться от дисскуса - но зачем приводить контраргументы из своего опыта)? Ясно же что, у билинга требования и задачи другие. Да и ответственность...

> [191] Sergey_Masloff (07.12.04 14:09)

> Я например пытался по "твоей" стратегии работать

Это о чем? Какой моей?

>Sergey_Masloff (07.12.04 14:03) [189]

Выдержка из SAP Help:

If a buffered table is modified, it is updated synchronously in the buffer of the application server from which the change was made. The buffers of the whole network, that is, the buffers of all the other application servers, are synchronized with an asynchronous procedure.

Entries are written in a central database table (DDLOG) after each table modification that could be buffered. Each application server reads these entries at fixed time intervals.

> [191] Sergey_Masloff (07.12.04 14:09)

Я начинаю понимать, какая ситуация в твоем случае.
У тебя есть руководство, которое не может рискнуть применить технологии, которые не прошли многолетнюю опробацию. Логичная позиция. У меня несколько другая ситуация. Я могу повлиять на архитектуру, что я и делаю. Результат пока успешен.

Если бы я платил деньги (лично) ни в жизнь бы не дал никому юзать новые технологии - только клиент-сервер с логикой на сервере. Почему? Опять же риск меньше. Но в нашем случае риск вроде как пока оправдывается.

← →
Sergey_Masloff (2004-12-07 14:21) [196]

← →
Sergey_Masloff (2004-12-07 14:22) [197]

> [196] Sergey_Masloff (07.12.04 14:21)

Ты бы анкету прописал - возраст интересно было бы знать.

Не понял:

> 161] Суслик © (07.12.04 12:29)
> 1. О среднем количестве сущностей (максимальное, прирост
> в год)
> 2. О количетве пользователей.
> 3. О критическом времени запроса
> 4. О интенсивности обновления данных (добавления)

> 1. Максимально расчетное кол-во сущностей - до 3 млн. Т.к. система бухучета, то цикл годовой (потом в архив). Т.е. за год 3 млн не набираем.
> 2. До 20

> [184] Sergey_Masloff (07.12.04 13:07)

> 1) На порядок больше у нас (кроме того на каждую сущность хранится история изменений но это я не считаю так как в работе не используется - только для разборов полетов)
> 2) По самым скромным оценкам на 2 порядка больше у нас

Т.е. сущностей - до 300 тыс. а пользователей до 1-го? :( Крута.

← →
Sergey_Masloff (2004-12-07 14:56) [200]

Думкин © (07.12.04 14:32) [199]
Когда на порядок больше это умножать на 10 надо а не делить ;-) Кто из нас математик? ;-)

Суслик © (07.12.04 14:23) [198]
>Ты бы анкету прописал - возраст интересно было бы знать.
Да не люблю я эти анкеты. У меня к ним идеосин... не помню вобщем то что у А.Подгорецкого к голубому цвету ;-) Когда
А так секретов нет возраст христа 33.

to Суслик:
Если угодно, могу о нашей системе немного рассказать.

>1. О среднем количестве сущностей (максимальное, прирост в год)
Система работает около года. Пока о среднем приросте за год мжно не говорить. Общее количество сгенерированных искусственных ключей - более 15 млн. Но там половина - учет серийников и еще часть - унаследованные данные. Но это, опять же, только искусственные первичные ключи. Там еще куча данных помимо этого.

>2. О количетве пользователей.
Если не ошибаюсь, в центральном офисе - в районе сотни. Еще филиалы, но там свои экземпляры базы + репликация.

>3. О критическом времени запроса
Если на часто повторяющихся операциях ждать приходится больше 10 секунд - повод оптимизировать логику. Поисковые выборки - до 30 секунд, зависит от критериев.

>4. О интенсивности обновления данных (добавления)
А фиг его знает... Когда как. Зависит от объемов продаж. Он не постоянный даже по месяцам. Вот, скоро пик начнется. :o)

>во-во, а я ввязался.
Вот только грязи не надо. :o) Не я это начал. :-P

>выбрасывая попутно пустой закрытый рекордсет, который ado
>радостно ловит
Ни разу не нарывался. Правда, ado не используем...

> Sergey_Masloff (07.12.04 13:07) [184]

Ну, тут можно привести хороший пример компании Мегафон. Согласитесь что объемы у них очень даже не маленькие. Так вот их информационная система, кроме билинга, реализована на платформе j2EE (билинговая система как я понял у них просто как подсистема).
И очень легко к ней подключаются любые ресурсы, будь то доступ через web или доступ к сервисам через сим меню телефона. Они рассказывали о своем решении на BDD в прошлом году,
весьма было интересно послушать.

> [200] Sergey_Masloff (07.12.04 14:56)

Вот я и делю. Ты сам пишешь:

> По самым скромным оценкам на 2 порядка больше у нас

То есть у Суслика на 2 порядка больше - то есть в 100 раз. Итого раз у них 20 - у тебя 0,2. :)))

> Вот только грязи не надо. :o) Не я это начал. :-P

ЧТо уже началось? Холи вор? Где, я тоже хочу.
В общем забей - все ок, никакой грязи - расценивай как шутку :)))

> >выбрасывая попутно пустой закрытый рекордсет, который ado
>
> >радостно ловит
> Ни разу не нарывался. Правда, ado не используем...

А потому, что вы как нормальные пользователи сервака используете его по назначению, а мы не совсем. Он у нас изнасилованный, но пока живой :))) Собственно я долго эту фичу искал в репортах не нашел, сервер мен искал - не нашел. Видно экзотика :)))
При чем не ясно чья ошибка. С одной стороны трейс явно говорит о перекомпиляции процедуры. С другой стороны ODBC работает ок - никакого линшнего рекрдсета. А АДО ловит его. С другой стороны я где-то видел фразу, что некоторые клиенты доступа умеют автоматически пропускать пустые закрытые рекордсеты. Может odbc это и делает, а ado не умеет. В общем я запарился с этой ошибкой разрбираться. Пришлось в адо брать следующий рекордстет пока не найду открытый.

← →
Sergey_Masloff (2004-12-07 15:09) [205]

Думкин © (07.12.04 15:04) [203]
если написано
>больше у нас
значит у Суслика меньше! ;-)
Там же не написано ЧЕМ У НАС.

Andryk © (07.12.04 15:03) [202]
>Так вот их информационная система, кроме билинга
Так а что у них информационного кроме биллинга? Ну в смысле объемно - информационного. Хотя согласен пример интересный.

> [205] Sergey_Masloff (07.12.04 15:09)

А... понял. Ты на суржике пишешь. Тады ой. Кто же фразы строит такие? :)

← →
Sergey_Masloff (2004-12-07 15:22) [207]

Думкин © (07.12.04 15:11) [206]
>А... понял. Ты на суржике пишешь. Тады ой. Кто же фразы строит >такие? :)

Уел, как говорится. Действительно, фраза получилась того... не очень. И ведь пятерка у меня по литературе была! А все почему - с кем поведешься... Прочитаешь пару постов Дмитрия О (не к ночи будь помянут) - ЗНАЕШ ИЩО НИ ТАК НАПИШИШЬ ;-)

> [207] Sergey_Masloff (07.12.04 15:22)

И ты уел. :) Мне надо покушать - вечер уже. Пошел я на отдых. :) Удачи!

to Суслик © (07.12.04 15:07) [204]:
>С другой стороны ODBC работает ок - никакого линшнего
>рекрдсета. А АДО ловит его.
У нас компоненты доступа работают через OLE DB, тоже поддерживают множественные наборы данных. Ничего лишнего не ловють.

> У нас компоненты доступа работают через OLE DB, тоже поддерживают
> множественные наборы данных. Ничего лишнего не ловють.

сами писали?
Мне это адо - уже воть где сидит.
Было бы время - сам бы забацал.

Собственно поймать лишка непросто. У меня даже стойкий пример не получился: то потухнет, то погаснет.

Sergey_Masloff (07.12.04 15:22) [207]

Приветствую!

По твоим оценкам, нагрузка на систему и объемы данных у вас больше или у нас ?

← →
Sergey_Masloff (2004-12-07 15:44) [213]

Игорь Шевченко © (07.12.04 15:32) [212]
>По твоим оценкам, нагрузка на систему и объемы данных у вас >больше или у нас ?
Я же почти не знаю про Эйшу (ты же ее ввиду имеешь). По моим ПРЕДПОЛОЖЕНИЯМ валовый объем данных сравним, нагрузка думаю у нас побольше. В принципе, если интерес есть я могу тебе чуть более подробно написать на мейл, сюда я при всем желании постить это не могу.

← →
Sergey_Masloff (2004-12-07 15:51) [214]

Удалено модератором
Примечание: Дубль

Sergey_Masloff (07.12.04 15:44) [213]

> сюда я при всем желании постить это не могу.

Разумеется. Аналогично.

> В принципе, если интерес есть я могу тебе чуть более подробно
> написать на мейл

whitefranz@hotmail.com

С уважением,

> Sergey_Masloff (07.12.04 15:51) [214]
> Игорь Шевченко © (07.12.04 16:07) [215]
Ну вот, так всегда - как рассказывать, так на площади, а как мерить - так за углом :)))))

> Sergey_Masloff (07.12.04 15:09) [205]
> Так а что у них информационного кроме биллинга? Ну в смысле
> объемно - информационного. Хотя согласен пример интересный.

Ну как же? База клиентов, блокирование и разблокирование клиентов, пополнение баланса, возможность через тырнет или симменю управлять набором услуг и т.д. там очень большая информационная система. Причем ей пользуются как и внутри компании, так и сами клиенты, просто разный интерфейс, для различных пользователей.
Кстати, написана она 4-мя человеками (как они сами говорили) и всего за 1.5 года (это о скорости разработки).

← →
Sergey_Masloff (2004-12-09 06:29) [218]

Игорь Шевченко © (07.12.04 16:07) [215]
<offtop>
дошел мейл? мне подтверждение не пришло а почта может глючить...
</offtop>

Delphi 2005 Найти похожие ветки