Сообщений в теме: 153

[kant]

kant, Вы, как сторонник веб-технологии клиента, посоветуйте - как можно организовать локальное кеширование множества справочников, необходимых для работы клиентской стороны, чтобы не передавать их с сервера при каждом чихе UI.
А то моя основная претензия к веб-мордам состоит в бешенном network i/o overhead-е: чтобы просто отобразить юзеру 2 кб данных приходится упаковывать их в 10-20 кб тегов с атрибутами, а чтобы отобразить красиво и с клиентским интерактивом - так вообще за 100кб на страницу легко можно перевалить.
Клиент-сервер overhead-а не имеет ибо все данные передаются в виде struct и обладает гораздо более широкими возможностями кеширования справочников (согласитесь, что кол-во типовых пользовательских операций не идет ни в какое сравнение с кол-вом случаев необходимости обновления exe-файла на машине юзера).
Что посоветуете? Можно как-то побороть overhead веб-морд и отсутствие в них возможности кеширования справочников (по крайней мере штатной)?

Все зависит от того на какой стек технологий вы ориентируетесь. Если MS то MS SQL -> WCF сервис -> морда на шарпе.
Если LAMP то Oracle -> (сервер приложений написанный на PHP или кому что удобно, + Memcache)-> морда на плюсах/Java/C#.
Очень большую роль влияет должна ли программа работать только на винде или поддерживать остальные ОС.
Если у меня есть право голоса в составлении бюджета то я бы посчитал что дешевле, разработать ПО или прикупить железок и более скоростной интернет. 1Г памяти ~ 25$. Сколько стоит час работы программиста? Математика простая.

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

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

[sobol]

Кстати о казахстанских программистах: Почему в НИТ-е программисты ходят в белых халатах как доктора, кто ни будь знает?

Ну это я так думаю дань традициям.. В 1992 году в ВЦ одного завода где я проходил практику - тоже ходили в белых халатах все - защита от статики и соблюдение чистоты при работе с магнитными лентами - в те времена техника все таки более чувствительная была...

[ndp]

Не могли бы вы дать примеры литературы/ресурсов, которые помогли бы отвечать на простые вопросы, которые специфичны именно для Oracla + хорошая справка по PL/SQL?

Ссылка была приведена для Вас в моем сообщении 09:34 (на второй странице).
Добавить могу только еще sql.ru, но там последние годы стало много мусора - школиё набигает...

[sobol]

Вот только Дельфи не трогайте... Контрпримером могу привести...

а что случилось то? и контрпример то зачем?
или это типа как в детстве "а у тебя еще хуже!" ?

Нет, просто последнее время все кому не лень пинают Дельфи - дескать IDE отстой и все кто на ней работают быдлокодеры, не способные написать нечто нормальное. А контрпример к тому, что есть продукты которые уступают Дельфи и тем не менее юзаются в республиканских масштабах. Каждый кулик свое болото хвалит, но за 1,5 десятка лет кодинга на Дельфи я убедился лично, что на сегодня более гибкой и более удобной среды разработки нет. Есть задачи конечно специфические, которые проще сделать на Си, не спорю, но для клиентских приложений, с учетом огромнейшего количества готовых VCL - лучше варианта ИМХО не придумать. А количество багов и багфиксов в том или ином продукте зависит не от IDE , а от прокладки между стулом и монитором.

[ndp]

Если LAMP то Oracle -> (сервер приложений написанный на PHP или кому что удобно, + Memcache)-> морда на плюсах/Java/C#.

Не-не-не... Это вы мне объясняете трехзвенку, а я речь веду о тонком клиенте (вопрос был про веб-морду)...
Приведенная Вами трехзвенка мне не нужна, у меня все прекрасно работает на клиент-сервере с 6000 одновременно подключенных юзеров по всей стране, которые совершают 1-1,5 млн операций в день, генерируя 20-30 Гбайт сетевого траффика в день. Тут все нормально.
Меня интересует другое: веб-морды все позиционируют как бесконечно масштабируемое без потери производительности решение, эдакая серебрянная пуля. Но, наблюдая как мне 40 минут выписывали свидетельство о смерти в юстиции, пользуясь тамошней веб-мордой (заполняется полей 25-30 при этом), я чуть сам не ушел в астрал - моих юзеров бы уже прибили или они сами бы застрелились от столь оперативного ПО...

Очень большую роль влияет должна ли программа работать только на винде или поддерживать остальные ОС.
Если у меня есть право голоса в составлении бюджета то я бы посчитал что дешевле, разработать ПО или прикупить железок и более скоростной интернет. 1Г памяти ~ 25$. Сколько стоит час работы программиста? Математика простая.
Ваши претензии к бешенному сетевому оверхеду не имеют особой почвы, если смотреть объективно то больший сетевой оверхед создает почтовый спам. Уж поверьте, намного лучше купить на те деньги, которые нужно будет заплатить хорошему специалисту за разработку и отладку супер-оптимизированной системы, оптоволокна в организацию. Оно в дальнейшем позволит существенно снизить затраты на собственно разработку, окупится на паре тройке внутренних проектов. Про оптоволокно я может и утрирую конечно, но в целом идея думаю ясна.

Не согласен. Математика отнюдь не проста: программист оплачивается один раз, для разработки/доработки ПО, а за каналы связи платить каждый месяц, причем каналы связи стоят в разы, а то и десятки раз больше, чем з/п даже высококвалифицированного программиста.
Почтовый трафик у нас 2-3Гбайта в день (против 20-30 Гб application traffic), поэтому мои претензии к бешенному оверхеаду более чем обоснованы.

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

++++++++++(+)

PS. кстати серверная память стоит отнюдь не 25$/1Gb, да и диски тоже не по ценам писюков...

Сообщение отредактировал ndp: 06.08.2010, 14:09:26

[akh]

Пара тройка правильно расставленных индексов и запросы стали отрабатываться за секунды. Народ был поражен. Мировое признание и все такое.

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

PS. Так что умение решить прикладную задачу не освобождает от знания теории ).

я б сказал не теории вообще, а конкретной СУБД.

Что самое странное это то что в фоксе индексы применялись очень активно, и правильно. А вы говорите ведро с битами

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

Не могли бы вы дать примеры литературы/ресурсов, которые помогли бы отвечать на простые вопросы, которые специфичны именно для Oracla + хорошая справка по PL/SQL?

если с инглишем нет проблем, то вот совсем свежак
http://c-books.info/...dition-gif.html

Сообщение отредактировал akh: 06.08.2010, 14:16:38

[kant]

То, что Вы не умеете готовить кошек, не значит, что они не вкусные...

Каким боком Гугл относится к ораклу, и с каких пор он выдает достоверные ответы, соответствующие действительному поведению программного продукта? Гугл суть - агенство новостей "Одна Бабка Сказала".
На сайт вендора зайти религия не позволяет?
Oracle RDBMS. полное собрание сочинений.

И это к сожалению не единичный случай.

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

Я действиельно не умею готовить кошек, о чем и сказал. Сам сервер меня устраивает, потому что базовый SQL там работает а для старта больше ничего и не надо. Но вот справочная система объективно убожеская.
Когда я приводил ссылки я хотел указать на то что базовые вопросы, у MS и MySQL достаточно хорошо проиндектированны гуглом и я могу получить большую часть информации простым единичным запросом к гуглу минуя навигационную схему оракла, что согласитесь экономит время. Моя религия позволяет ходить на сайты вендора и я там был, и мне это не сильно помогло.
Чтобы проставить границы применения справочной системой, я могу описать примерную ситуацию.
У меня был сконфигурированный сервер Oracle и БД на нем. Были остатки схемы БД, и не было никакой информации о том какие индексы были применены к схеме БД. Файлы БД лежали в нестандартном месте, БД состояла более чем из 2 файлов. Надо было сделать автоматизированный процесс создания БД. В целом рядовая ситуация для ДБА. не требующая более чем полчаса-час на выполнение. Я пробился с ней порядка 8-12 часов суммарно, просто потому что я не имел ни малейшего понятия с какой стороны подступиться к решению задачи.

Гугл имеет огромное отношение к работе в IT. Если честно, то большинство средней сложности проблем можно решить просто обратившись к гуглу. Очень часто вы являетесь не первым человеком, который попал в схожую ситуацию и гугл поможет в решении проблема. Именно по этому я при решении проблем в первую очередь обращаюсь к гуглу, а не к сайту вендора. Попробуйте получить справку по полному синтаксису интересущющей вас команды для PL SQL одним запросом к гуглу. Можете сравнить количество примеров которые есть в документации по основным командам на сайте MS. Я понимаю что возможно я сильно долго работал с MS что делает мне понятным способ поиска информации, но он так же хорошо заработал и с MySQL. Я получил доходчивую информацию о том что мне было нужно, просто обратившись к гугулу.

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


Коментарий про "программиздов" я пожалуй не буду детально освещать

[sobol]

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

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

[kant]

я б сказал не теории вообще, а конкретной СУБД.

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

если с инглишем нет проблем, то вот совсем свежак
http://c-books.info/...dition-gif.html

Спасибо, английский не проблема, почитаю.

[xxel]

Нет, просто последнее время все кому не лень пинают Дельфи

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

... что есть продукты которые уступают Дельфи ...

а

те же qip, download manager, bat

ни о чем не говорят? или ищем в постах только то что не нравится?

Каждый кулик свое болото хвалит, но за 1,5 десятка лет кодинга на Дельфи я убедился лично, что на сегодня более гибкой и более удобной среды разработки нет.

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

....количества готовых VCL....
А количество багов и багфиксов в том или ином продукте зависит не от IDE ,

От IDE вообще почти ничего не зависит кроме скорости рисования формочек.
А количество багов и багфиксов в том или ином продукте зависит от свойств (всех) языка программирования.

[ndp]

Я действиельно не умею готовить кошек, о чем и сказал. Сам сервер меня устраивает, потому что базовый SQL там работает а для старта больше ничего и не надо. Но вот справочная система объективно убожеская.

У меня возникает когнитивный диссонанс, когда люди противоречат сами себе...

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

А при чем тут именно Оракл? С таким же успехом я, как ораклист, буду те же 8-12 часов биться с установкой MSSQL, ибо я его так же не знаю, как и Вы - Оракл...

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

ИМХО, порочная практика: документацию нужно читать оригинальную (это касается не только продуктов Оракл), а не использовать сомнительные источники...

Попробуйте получить справку по полному синтаксису интересущющей вас команды для PL SQL одним запросом к гуглу.

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

Я понимаю что возможно я сильно долго работал с MS что делает мне понятным способ поиска информации,

Я тоже к этому склоняюсь... MS приучает людей "махать мышкой", а Оракл - это Unix-стиль, ориентированный на выполнение действий вводом команд, благодаря чему, кстати, я могу запросто администрировать/девелопить БД из любой точки планеты имея до нее канал связи 9600 бит/сек и мне сто лет не нужен для этого графический интерфейс.
Данный стиль управления сервером приучает людей думать, а не просто наугад тыкать мышкой по "похожим на то, что я хочу сделать" кнопочкам...
Если в следующий раз столкнотесь с Ораклом, воспринимайте его не как велосипед, на котором каждый - захотел и поехал, пусть медленно, зато просто, а как военный истребитель - сначала досконально изучил рычаги управления, а потом сел за штурвал, полетел и никто тебе не страшен на пути .

[kant]

Если LAMP то Oracle -> (сервер приложений написанный на PHP или кому что удобно, + Memcache)-> морда на плюсах/Java/C#.

Не-не-не... Это вы мне объясняете трехзвенку, а я речь веду о тонком клиенте (вопрос был про веб-морду)...
Приведенная Вами трехзвенка мне не нужна, у меня все прекрасно работает на клиент-сервере с 6000 одновременно подключенных юзеров по всей стране, которые совершают 1-1,5 млн операций в день, генерируя 20-30 Гбайт сетевого траффика в день. Тут все нормально.
Меня интересует другое: веб-морды все позиционируют как бесконечно масштабируемое без потери производительности решение, эдакая серебрянная пуля. Но, наблюдая как мне 40 минут выписывали свидетельство о смерти в юстиции, пользуясь тамошней веб-мордой (заполняется полей 25-30 при этом), я чуть сам не ушел в астрал - моих юзеров бы уже прибили или они сами бы застрелились от столь оперативного ПО...

Очень большую роль влияет должна ли программа работать только на винде или поддерживать остальные ОС.
Если у меня есть право голоса в составлении бюджета то я бы посчитал что дешевле, разработать ПО или прикупить железок и более скоростной интернет. 1Г памяти ~ 25$. Сколько стоит час работы программиста? Математика простая.
Ваши претензии к бешенному сетевому оверхеду не имеют особой почвы, если смотреть объективно то больший сетевой оверхед создает почтовый спам. Уж поверьте, намного лучше купить на те деньги, которые нужно будет заплатить хорошему специалисту за разработку и отладку супер-оптимизированной системы, оптоволокна в организацию. Оно в дальнейшем позволит существенно снизить затраты на собственно разработку, окупится на паре тройке внутренних проектов. Про оптоволокно я может и утрирую конечно, но в целом идея думаю ясна.

Не согласен. Математика отнюдь не проста: программист оплачивается один раз, для разработки/доработки ПО, а за каналы связи платить каждый месяц, причем каналы связи стоят в разы, а то и десятки раз больше, чем з/п даже высококвалифицированного программиста.
Почтовый трафик у нас 2-3Гбайта в день (против 20-30 Гб application traffic), поэтому мои претензии к бешенному оверхеаду более чем обоснованы.

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

++++++++++(+)

PS. кстати серверная память стоит отнюдь не 25$/1Gb, да и диски тоже не по ценам писюков...

эдакая серебрянная пуля это развод маркетологов Своя голова должна быть на плечах.
Я навскидку про цены, честно все надо считать, много деталей и ньюансов.
Сервер приложений так или иначе мне кажется нужен организации, просто потому что иногда надо делать рассылочки клиентам и прочую автоматизированную лабуду. Возможно в вашем случае это часть инфраструктуры компании.
Касательно юриста и 40 минут, ну как бы в гос масштабах при текущей ситуации в КЗ, я бы не стал повсеместно внедрять веб-морды.
Но внутри организации вебморда это просто счастье. Опять таки говорюсь в большинстве случаев. Если у вас заносится много информации, то возможно веб морда и лишняя. А может быть можно настроить вебсервер зиповать отправляемый контент, может трафик уменьшить. Потому что если у вас 20-30Гб компрессированного трафика то это конечно повод задуматься.
Я не оголтелый фанатик веба. Если надо будет и десктоп подойдет, просто я считаю что сперва надо рассматривать веб, а потом если он не подойдет, то десктоп. Или как минимум, не вбрасывать его сразу жена этапе анализа проекта.
Далеко не все работают при ваших масштабах трафика. Что вы скажете про систему учета рабочего времени для компании у которой работают 10 человек. Она ведь так много трафика не генерирует, а польза от нее может быть полезной. Или например система тикетов, для общения с клиентами. Трафик копеечный, согласитесь ведь, зато можно клиентов заставить отвечать за свои слова.

[ndp]

время оно на месте не стоит, в отличии от дельфей

вот не знают этого программисты того же MS, и всё пишут и пишут свои продукты (оси всякие, офисы, динамиксы и т.д.) на старом добром Visual C++, которому уже лет -надцать...

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

Вы путаете производство продукта "Borland Delphi" (это - бизнес), и его применение потребителями (это уже другой бизнес).
Borland виноват в том, что он в лице 6-й версии произвел настолько удобную и гибкую, наращиваемую IDE, что у пользователей надолго исчезла необходимость переходить на ее следующую версию, которая, естественно, тупо не стала продаваться - программистам незачем было ее покупать, их и 6-я версия устраивала.
Но это вовсе не говорит о том, что Delphi плох.

[Иксилимьюз]

Так же к списку Made in KZ можно прибавить ПО от компании Sector

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

[ndp]

Я навскидку про цены, честно все надо считать, много деталей и ньюансов.

Ну вот, опять... Не считал, но знаю, что дороже...
А я Вам по секрету скажу: в крупной организации требуется 200 выделенных каналов 128кбит/сек с шифрацией трафика, каждый стоит примерно по 1 куе/месяц... Что составляет 200 тыс уе в месяц. Программистов - 5 чел. Стоимость каналов и программистов - не сравнима, даже если нанять тучу дешевых мальчиков-студентов-ПХПшников, из-за чего каналы придется расширять раз в 5-6 под подешевке разрабатываемые веб-морды.

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

Зачем мне промежуточное звено AppServer-а, если в Оракле куча функционала на все случаи жизни? Зачем мне на боевом железе лишние межпроцессные взаимодействия жрущие память и такты? Кроме как для просадки производительности и завышения требований к железу? Рассылочки и прочая автоматизированная лабуда (вплоть до формирования xls & doc-файлов) делаются встроенными средствами Оракла. Объясните пожалуйста - зачем нужен AppServer?...
На мой взгляд, AppServer - это костыль, которым лечат убогую функциональность неудачно выбранной СУБД, вместо приобретения более функциональной, не более того...
Либо его применяют в тех случаях, когда разработчику серверной части влом изучать средства, которыми располагает выбранная СУБД, и тогда её возможности используются на 2% и это уже не база данных, а свалка данных...

Касательно юриста и 40 минут, ну как бы в гос масштабах при текущей ситуации в КЗ, я бы не стал повсеместно внедрять веб-морды.

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

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

Это давно, 5 лет назад, сделано.Причем встроенными средствами Оракла, прямо внутри хранимых процедур СУБД и средствами СУБД (не внешние команды оси).

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

Во! Золотая мысль!
То, чего я от Вас добивался.
Мысль о том, что перво-наперво при проектировании архитектуры приложения необходимо сравнивать в численных выражениях максимальное время ответа, допустимые удельный трафик, процессорное время и т.п. на 1 user-operation и т.д., возможности технологии и потребности клиентского ПО (кеширование справочников, работа с локальной аппаратурой машины пользователя) - эту мысль надо высечь на лбу каждого разработчика. И в первую очередь - на лбу разработчиков веб-морд, чтобы они их не тыкали во все углы...

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

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

Сообщение отредактировал ndp: 06.08.2010, 15:52:33

[kant]

У меня возникает когнитивный диссонанс, когда люди противоречат сами себе...

Вполне возможно у меня не достаточно конктретная манера вести диалог, а вы не хотите посмотреть на проблему с моей точки зрения. Меня не устраивает остутствие нормальной ИНТЕГРАЦИИ справочной системы СУБД Oracle с поисковыми системами. Я знаю что я научусь со временем правильно готовить СУБД Oracle. Но справочная система это дополнительная инфраструктура, которая на данный момент является обязательной при продаже любого IT продукта. Если эта доп услуга хуже чем у конкурентов, то это понижает привлекательность продукта на рынке, мне так кажется ) Вот я какая вредный. Хочу чтобы как у остальных гуглом можно было пользоваться.

А при чем тут именно Оракл? С таким же успехом я, как ораклист, буду те же 8-12 часов биться с установкой MSSQL, ибо я его так же не знаю, как и Вы - Оракл...

Установка и настройка мне были не нужны, мне нужно было просто перенести БД с данными и некими неизвестными мне настройками на другой сервер в неприкосновенности. Взял из одного места и положил в другом. К сожалению не получилось быстро. Мой скепсис основан еще на том, что подобную задачу у для MySQL, при том же уровне владения им, я осилил быстрее. Благодаря гуглу, а не документации. Проблема в документации к современным СУБД, в том что чтобы прочитать ее, требуется достаточно большой объем времени. Так как я не знал с чего начинать, мне улыбалась невеселая перспектива читать все подряд что есть в документации. Потому что система организации данных в Oracle выглядит несколько по другому, чем в MS SQL и MySQL.

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

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

Я тоже к этому склоняюсь... MS приучает людей "махать мышкой", а Оракл - это Unix-стиль, ориентированный на выполнение действий вводом команд, благодаря чему, кстати, я могу запросто администрировать/девелопить БД из любой точки планеты имея до нее канал связи 9600 бит/сек и мне сто лет не нужен для этого графический интерфейс.

MS делает удобные продукты, и каждый или пользуется по своему разумению. В силу своих умений и знаний. MS тут не причем. у продуктов MS тоже есть консольные утилиты. Да это убогие утилиты по сравнению с терминалом линукса, но в экстремальных ситуациях, а для меня 9600 бит/сек это экстремальная ситуация, позволяют выполнить то что надо сделать с медленным интернетом.
Да, и кстати. Времена кастовости Unix/Linux канули в лету. Все больше и больше бизнес клиентов стучатся с просьбой приютить у себя. Они приносят свои традиции в культуру общения.
Владелец бизнеса вполне может потребовать перенести инфраструктуру на другую платформу, и тебе при необходимости прийдется это сделать. Не факт что не появится что-то новое в мире операционных систем, и прийдется учиться снова.

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

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

Сообщение отредактировал kant: 06.08.2010, 15:48:57

[SIKTYM]

Почитатйе книгу Getting Real от 37signals...
Меньше кода, меньше ...меньше!

[kant]

Ну вот, опять... Не считал, но знаю, что дороже...
А я Вам по секрету скажу: в крупной организации требуется 200 выделенных каналов 128кбит/сек с шифрацией трафика, каждый стоит примерно по 1 куе/месяц... Что составляет 200 тыс уе в месяц. Программистов - 5 чел. Стоимость каналов и программистов - не сравнима, даже если нанять тучу дешевых мальчиков-студентов-ПХПшников, из-за чего каналы придется расширять раз в 5-6 под подешевке разрабатываемые веб-морды.

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

Зачем мне промежуточное звено AppServer-а, если в Оракле куча функционала на все случаи жизни? Зачем мне на боевом железе лишние межпроцессные взаимодействия жрущие память и такты? Кроме как для просадки производительности и завышения требований к железу? Рассылочки и прочая автоматизированная лабуда (вплоть до формирования xls & doc-файлов) делаются встроенными средствами Оракла. Объясните пожалуйста - зачем нужен AppServer?...
На мой взгляд, AppServer - это костыль, которым лечат убогую функциональность неудачно выбранной СУБД, вместо приобретения более функциональной, не более того...
Либо его применяют в тех случаях, когда разработчику серверной части влом изучать средства, которыми располагает выбранная СУБД, и тогда её возможности используются на 2% и это уже не база данных, а свалка данных...

Так не честно. Вы делаете подмену понятий. Вы пытаетесь назвать СУБД, то что давно уже не просто СУБД, а СУБД + AppServer. По факту это довески, которе стали недавно(MS) появляться в СУБД и являются AppServer.

То, чего я от Вас добивался.
Мысль о том, что перво-наперво при проектировании архитектуры приложения необходимо сравнивать в численных выражениях максимальное время ответа, допустимые удельный трафик, процессорное время и т.п. на 1 user-operation и т.д., возможности технологии и потребности клиентского ПО (кеширование справочников, работа с локальной аппаратурой машины пользователя) - эту мысль надо высечь на лбу каждого разработчика. И в первую очередь - на лбу разработчиков веб-морд, чтобы они их не тыкали во все углы...

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

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

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

[sobol]

Вы путаете производство продукта "Borland Delphi" (это - бизнес), и его применение потребителями (это уже другой бизнес). Borland виноват в том, что он в лице 6-й версии произвел настолько удобную и гибкую, наращиваемую IDE, что у пользователей надолго исчезла необходимость переходить на ее следующую версию, которая, естественно, тупо не стала продаваться - программистам незачем было ее покупать, их и 6-я версия устраивала. Но это вовсе не говорит о том, что Delphi плох.

100% поддерживаю. Только наверное не 6-я, а 7-я версия. Что касается юникода, то ничто не мешает созданный ранее на 7-й версии продукт перекомпилировать в D2009 и получить то что требуется, согласно велениям времени и что более важно - потребностям заказчика.

[ndp]

Если вы мне подкинете еще пару-тройку подобных ресурсов,

Ну Вам необходимо хотя бы изучить вот это:
Oracle® Database Concepts
Oracle® Database Administrator's Guide
Oracle® Database SQL Language Reference
Oracle® Database PL/SQL Language Reference

Так не честно. Вы делаете подмену понятий. Вы пытаетесь назвать СУБД, то что давно уже не просто СУБД, а СУБД + AppServer. По факту это довески, которе стали недавно(MS) появляться в СУБД и являются AppServer.

Сорри... То, что Вы называете СУБД, в моем понятии - огрызок . Просто в Оракле встроенные язык написания хранимых программных единиц (функции/процедуры/пакеты/триггеры), пакеты расширенной функциональности, а затем и встроенная Java-машина (интегрированная с СУБД) были с незапамятных времен, поэтому как-то даже в голову не приходит изобретать лисапед...
Кстати, имейте ввиду - у Оракла есть бесплатная версия СУБД - Oracle Express Edition. Она правда без всяких мощных плюшек, ради которых берут Enterprise Edition, и с ограничением на размер БД в 4Гб, но зато сразу со встроенным APEX (фреймворк для клепания веб-интерфейса к БД).

Сообщение отредактировал ndp: 06.08.2010, 16:52:49