Я только начинаю осваивать ДОТНЕТ, да и вообще Студию .НЕТ, ранее работал с Дельфи. У меня такой вопрос закрался, как вообще работать с базами, помимо MS SQL Server ? Например с Interbase/FireBird ? Для Дельфи существует масса отличных компонентов для различных бд.
Здравствуйте, STEEL, Вы писали:
STE>Я только начинаю осваивать ДОТНЕТ, да и вообще Студию .НЕТ, ранее работал с Дельфи. У меня такой вопрос закрался, как вообще работать с базами, помимо MS SQL Server ? Например с Interbase/FireBird ? Для Дельфи существует масса отличных компонентов для различных бд.
Так же множеством отличных провайдеров для разных БД.
Делфи — это отстой.... Я сам раньше на нём писал.....но когда перешёл на .НЕТ — я попал в другой мир....где всё сделано для программиста и для разработки высококачественных продуктов...
Мало того, .НЕТ открывает гораздо больше возможностей и методов решения для любых хадач.... Поэтому, когда я слышу, что кто-то говорит, что .НЕТ по сравнению с Делфи фигня или, что возможности Делфи не намного ниже, чем .НЕТ — мне смешно это слышать. И складывается такое впечатление, что человек, кот. так говорит, пишет это из-за ограниченности в информации...или из-за того, что он просто должен сидеть на Делфи и у него нет возможности перейти на .НЕТ. Т.о. он пытается отстоять, что тем, чем он занимается — перспективно. Но тем самым он обманывает самого себя....
А что вы будете делать, когда выйдет новый пакет "Windows"? В которой не будет Вин Апи? М? Что тогда?
Понятно, что пройдёт лет 5 пока она станет на ноги, но всё равно, уже понятно, что Делфи — устаревает для разработки приложений....точно также, как ПХП для интернет приложений...
Вообщем, над этим можно много дискуссировать....
Сразу прошу прощения, если задел чьё-то самолюбие или кому-то показались мои слова обидными...
А к FireBird Вам лучше коннектиться через ОЛЕ ДБ провайдер или через родной (но так я, по правде, не делал) провайдер.
Тут технология АДО.НЕТ, а не просто АДОшка. Концепция другая. Учите .НЕТ — вы на правильном пути
Вот именно о таком обиженном человеке я и говорил...и просил не принимать мои слова близко к сердцу, а тем более не писать оскорблений... Поэтому, если кто-то хочет что-то мне сказать, прошу это делать корректно, а не плеваться дурацкими шутками уровня подготовительной группы детского сада....
....ну с твоим "взрослым" ником не посоперничаешь.... Сразу видно опытный программист, который во многом разбирается....а особенно — в .НЕТ...
У меня тут весь офис сиеётся над твоими сообщениями
>> Мало того, .НЕТ открывает гораздо больше возможностей и методов решения для любых хадач....
В чем заключается больше возможностей? Почему-то когда говорят о возможностях, то это только возможности для программистов. А где возможности для пользователей. Что выигрывает пользователь от увеличения эфемерных возможностей программиста? Если производитель выпускает новую видеокарту, вы ждете от нее лучшего быстродействия не так ли. Будете ли вы покупать эту видеокарту, если она будет медленнее уже установленной у вас, но зато вам скажут, что она сделана по новой технологии. А в виде плюсов технологии будут говорить, что в применяя эту технологию производителю стало гораздо легче работать. Вам как пользователю абсолютно безразлично насколько хорошо и комфортно работалось производителю. Вам нужен конечный результат.
Не кажется ли вам, что нет таких популярных продуктов типа офиса на NET не потому, что что-то там долго переписывать (за 5 лет то), а потому, что пользователь сможет сравнить с тем , что у него уже есть и отдать предпочтение старому доброму Win API. Честно говоря, мне все равно на чем написано приложение, но если мне есть с чем сравнить вы думаете я не буду учитывать как приложение работает на моем компьютере?
>>или из-за того, что он просто должен сидеть на Делфи и у него нет возможности перейти на .НЕТ. Т.о. он пытается отстоять, что тем, чем он занимается — перспективно. Но тем самым он обманывает самого себя....
А я не пойму, хоть убей, чем Delphi не перспективно. Что такое страшное грядет? Windows без Win API? Что-то с трудом верится. Даже если представить что это будет, то кому она будет нужна без поддержки Win API приложений. И самое смешное во всем этом то, что агитаторы NET все время пекутся о перспективах и будущем, такое ощущение, что они там уже живут. При социализме тоже все пеклись о будущем, забывая при этом о настоящем. И что в итоге? Будущее так и не наступило, а настоящее потеряли. Вы так и не поняли, что Хейльсберг специально ушел в MS, чтобы изнутри подточить ее NET’ом в пользу более производительного своего детища – Delphi.
Я ни в коем случае не умаляю возможностей NET, но не кажется ли вам господа, что закон сохранения работает и в данном случае. Выигрываете в скорости разработки, теряеете в производительности готового продукта. Убрали проблемы работы с памятью, получили проблемы работы с памятью самого GC. (Не надо только говорить что их нет в ресурсоемких приложениях). Как говорится чисто не там где метут, а там где не сорят. Что особенно актуально, когда вы, как программист даже не в курсе, кто у вас в приложении сорит, и кто и когда подметет.
Пару слов про ADO.NET. Все хорошо до поры до времени. Вот есть у вас табличка мастер и есть табличка деталь. Вам надо их обработать (не путать с просмотром). А то постоянно слышно, да зачем тебе 100000 записей на клиенте, он все равно их не просмотрит. А мне и не надо чтоб он их просматривал, мне надо чтобы моя программа их обработала по определенному алгоритму. И что в этом случае делать? Тащить 100 тыс. записей мастера и 4 млн деталей? Чтобы работали связи в DataSetе получается так и надо поступить. Или надо брать по 1 записи мастера и все записи деталей. Обработал, взял следующую. Но тогда чем это лучше Delphi реализаций? А может хуже? Там выделил память поработал, освободил. А здесь получается, выделил, выделил, выделил и хрен его знает когда освободил. Понятно, что память дешевая. Но если у меня много комнат, это не значит, что их все надо загадить.
Вобщем рановато еще Delphi хоронить. Ой, рановато. Особенно когда дело касается работы с базами данных.
>>У меня тут весь офис сиеётся над твоими сообщениями
Интересно, у тебя что офис по субботам работает? У ж не от недостатка ли производительности в выходные трудитесь?
А BlackTigerAP можно уважать уже за его активность здесь, причем весьма полезную. Так что нечего ржать так громко.
<Вы так и не поняли, что Хейльсберг специально ушел в MS, чтобы <изнутри подточить ее NET’ом в пользу более производительного <своего детища – Delphi. такого хода со стороны Хейльсберга я и не представлял себе...
Молодец он... и СуперДжек тоже
2 SuperJack
а быстрее всего работают приложения, написанные на ассемблере
и память используют оптимально и программист всегда вкурсе подметания и сорения и т.д. и т.п.
чего не пишете на нём? ну подумаешь, немного больше писать)) зато какой выигрыш в производительности!
сомневаюсь, что Хейльсберга такой фанатичный идеалист просто ему наверно намного больше денег предложили, вот и всё
а скажите, Делфи всё ещё развивается? или все пользуются уже фиксированой базой компонентов, модулей и прочего? (не считая делфи под .нет)
ещё вопрос — Делфи начался сразу как крутой язык программирования или всё таки как процедурный Паскаль, а уж потом доразвился до Делфи? ТЕМ БОЛЕЕ версия 6-7. а Сшарп /фреймфорк какая версия ?
знаете, это похоже на ситуацию, когда программист с 30-летим стажем, который уже многое знает и знает как сделать, знает всякие лазейки и хитрости пинает новичка, который только год-два работает, используя малую часть своих возможностей, не такого изощренного. ну вобщем суть ясна, да?
Давайте все-таки не будем забывать, что Хайльсберг является разработчиком языка C#, но не платформы .NET в целом. Поэтому разговоры типа "изнутри подточить .NET-ом" тянут мягко говоря не более, чем на досужие байки.
>>и память используют оптимально
Память они используют оптимально лишь в том случае, если разработчик соблюдает определенные требования к написанию кода. Сделать ошибку, а значит и получить утечку памяти, здесь куда как проще.
>>программист всегда вкурсе подметания и сорения и т.д. и т.п.
Ой, что-то сильно сомневаюсь насчет этого. Иначе бы не появлялось проектов вида "сборщик мусора для С++".
>>Делфи всё ещё развивается?
Со стороны Borlaтв — нет. Следи за фронтовыми сводками
>>Делфи начался сразу как крутой язык программирования или всё таки как процедурный Паскаль
Delphi начался как Object Pascal
>>это похоже на ситуацию, когда программист с 30-летим стажем, который уже многое знает и знает как сделать, знает всякие лазейки и хитрости пинает новичка, который только год-два работает, используя малую часть своих возможностей, не такого изощренного. ну вобщем суть ясна, да?
Не совсем так. .NET разрабатывали отнюдь не юнцы И за плечами не один год стажа...
P.S. Кстати, с памятью в .NET нужно все равно аккуратно работать. Порой, непроставленный Dispose может вылиться в грандиозную утечку памяти и падение производительности.
>>Память они используют оптимально лишь в том случае, если >>разработчик соблюдает определенные требования к написанию >>кода.
это я для наглядности. кстати, это относиться к любому языку.
>>Ой, что-то сильно сомневаюсь насчет этого. Иначе бы не >>появлялось проектов вида "сборщик мусора для С++".
я про ассемблер! там изначально программист должен знать что и где, чтобы что-то написать. но это, вобщем-то, не важно. Суть в том, что одно выигрывает за счет другого
>>Со стороны Borlad — нет
думаю, одно это должно кое-что говорить)))))
>> Delphi начался как Object Pascal
сути это не меняет всё откуда-то начинается, и если в версии 1.0 или даже 2.0 что-то не так, то наверно к версии 3.0 это уже будет ТАК это не учитывая явных преимуществ
>>Не совсем так. .NET разрабатывали отнюдь не юнцы И за >>плечами не один год стажа...
я про саму технологию, а не разработчиков!
Здравствуйте, fmiracle, Вы писали:
F>Здравствуйте, STEEL, Вы писали:
STE>>Я только начинаю осваивать ДОТНЕТ, да и вообще Студию .НЕТ, ранее работал с Дельфи. У меня такой вопрос закрался, как вообще работать с базами, помимо MS SQL Server ? Например с Interbase/FireBird ? Для Дельфи существует масса отличных компонентов для различных бд.
F>Так же множеством отличных провайдеров для разных БД.
F>тут для для IB/FB: F>http://www.firebirdsql.org/index.php?op=files&id=netprovider
F>Еще можно более-менее универсально через ODBC&OleDB, но "родной" .net-провайдер обычно лучше.
А можно поинтересоваться чем лучше .Net провайдер от связки OleDb Provider — ADO.Net ?
AM>А можно поинтересоваться чем лучше .Net провайдер от связки OleDb Provider — ADO.Net ?
Убирается лишний посредник и имеется больше информации о том, с какой базой работаем, ее детали, что потенциально дает следующие бонусы:
1. Расширения, специфичные для данной базы (типа ConnectionBuilder и т.д.) — не критично, но иногда весьма удобно.
2. Более эффективные обращения к базе — например, для управления соединениями, запроса прекомпиляции команд или извлечения результатов.
3. Опять же, поскольку четко известно что за база, может предоставляться более подробная информация об ошибках — либо иерархией исключений, либо полями в единственном классе исключения.
В общем и целом родной .net провайдер для конекретной базы может быть эффективнее в работе и при этом удобнее чем OleDb, хотя, конечно же, всегда можно написать провайдер неудобным и неэффективным
Здравствуйте, fmiracle, Вы писали:
AM>>А можно поинтересоваться чем лучше .Net провайдер от связки OleDb Provider — ADO.Net ?
F>Убирается лишний посредник и имеется больше информации о том, с какой базой работаем, ее детали, что потенциально дает следующие бонусы:
F>1. Расширения, специфичные для данной базы (типа ConnectionBuilder и т.д.) — не критично, но иногда весьма удобно.
F>2. Более эффективные обращения к базе — например, для управления соединениями, запроса прекомпиляции команд или извлечения результатов.
Все зависит от прямоты рук разработчика провайдера. Если сравнивать с System.Data.OleDb то там что-то совсем все плохо. Это лишь неудачная попытка использовать OleDb в контексте .Net.
F>3. Опять же, поскольку четко известно что за база, может предоставляться более подробная информация об ошибках — либо иерархией исключений, либо полями в единственном классе исключения.
Набор стандартных ошибок OleDb ~ 200. Набор контролируемым ошибок БД приложением определенно невелик. Гораздо эффективнее не контролировать, а исключать возможность их появления на уровне логики. Я обычно ограничиваюсь проверкой — была ошибка или нет с выводом её описания. Хотя если такие ошибки появляются — значит есть проблемы в реализации приожения Иерархия исключений — наверное плюс.
F>В общем и целом родной .net провайдер для конекретной базы может быть эффективнее в работе и при этом удобнее чем OleDb, хотя, конечно же, всегда можно написать провайдер неудобным и неэффективным
Насчет производительности Native Provider-a не могу судить. Хотя если оценить общую тенденцию производительности .Net based приложений не думаю, что он будет эффективнее работать с DB API чем его com-аналог.
Небольшое резюме:
1. Существующая реализация System.Data.OleDb имеет недоработки и весьма неэффективную реализацию. Есть подозрения, что все это следствия помыток обеспечить совместимость с наибольшим количеством типов баз данных, хотя наверное Правильно было бы реализовать весь потенциал OleDb интерфейсов, а их реализацию с другой стороны оставить на откуп разработчикам OleDb Provider-ов
2. Native провайдер безусловно при грамотной реализации способен обеспечить большую функциональность, специфичную для конкретной базы данных, но вместе с тем лишает разработчика использовать свои приложения с различными БД.
Здравствуйте, fmiracle, Вы писали:
AM>>А можно поинтересоваться чем лучше .Net провайдер от связки OleDb Provider — ADO.Net ?
F>Убирается лишний посредник
Это декларировалось для каждой технологии доступа к БД. Потом народ наступал на грабли реализации и ему это было уже до.... фонаря.
F>1. Расширения, специфичные для данной базы (типа ConnectionBuilder и т.д.) — не критично, но иногда весьма удобно. F>2. Более эффективные обращения к базе — например, для управления соединениями, запроса прекомпиляции команд или извлечения результатов. F>3. Опять же, поскольку четко известно что за база, может предоставляться более подробная информация об ошибках — либо иерархией исключений, либо полями в единственном классе исключения.
Ты не поверишь, все это есть в рамках OLEDB интерфейсов. Расширения тоже можно сваять, но вот вопрос — зачем?
-- Пользователи не приняли программу. Всех пришлось уничтожить. --
а при установке приложений, написанных с использованием этого провайдера, на
"голую" машину его нужно устанавливать?
Re: C# и Базы данных
От:
Аноним
Дата:
31.05.06 15:31
Оценка:
eisernWolf, причем тут флем? Лучше почитайте ето:
Приглашаем .NET експерта с опытом работы в .NET не менее 4-х лет и с умением свободно изьясняться хотя бы по-английски (обязательно). Дополнительно к етому желательно еще владение немецким и/или французским.
Cпециальные требования: владение и практические навыки следующих технологий:
Операционные системы 9x/ME, NT4/2000XP c C/C++, ATL, MFC, STL, WIN32API, (D)COM программирование .NET Framework 1.1 приложений (WINForms, Libraries, Controls c C# Interoption COM/.NET); системное программировние Threads, Processes & Synchronisation; твердые навыки работы в Microsoft Visual Studio .NET2003; хорошие знания в версионировании c CVS; твердые навыки работы c Macrovision InstallShield 11 Premier; программировние на VB6 в Outlook Context; Outlook COM AddIns, Outlook Object Library, CDO, MAPI
Оплата 3,5-4 Т евро в месяц (в зависимости от налогов). О рабочей визе позаботяться, но нужен Microsoft Certified!
Рабочее место на юге Германии. В перспективе рабочее место переезжает в франкоязычную часть Швейцарии. В коллективе 12 человек, из них четверо русскоязычных коллег.
Обращаться ко мне сюда. Потом пообщаемся по е-мeйлу.
>>Приглашаем .NET експерта с опытом работы в .NET не менее 4-х лет и с умением свободно изьясняться хотя бы по-английски (обязательно).
Это есть.
>>Дополнительно к етому желательно еще владение немецким и/или французским.
Французский не знаю вообще. Немецкий когда-то учил в школе.
>>Операционные системы 9x/ME, NT4/2000XP c C/C++, ATL, MFC, STL, WIN32API, (D)COM программирование .NET Framework 1.1 приложений (WINForms, Libraries, Controls c C# Interoption COM/.NET);
C MFC и ATL не работал. Остальное свободно.
>>системное программировние Threads, Processes & Synchronisation; твердые навыки работы в Microsoft Visual Studio .NET2003; хорошие знания в версионировании c CVS;
Работаю с Subversion.
>>твердые навыки работы c Macrovision InstallShield 11 Premier
Не использую.
>>программировние на VB6 в Outlook Context; Outlook COM AddIns, Outlook Object Library, CDO, MAPI
VB6 знаю (4 года опыта), работал с OLE, но насчет адд-инов я пасс.
>>О рабочей визе позаботяться, но нужен Microsoft Certified!
На данный момент не имею возможности покинуть свое место жительства на длительный срок.
Не много про Delphi/ Я тут вычитал на королевсте что Delphi будет жить и бизнес средств разработки выделяется в отдельный и контора будет называться DevCo они ищут спонсоров для этого бизнеса. Так что поживем увидим что из этого получится. А то последнии версии их средств разработки как то не очень радуют
Вроде нет..
Я почти не пользовался Firebird за исключением пробы применить его как embedded (но только пробы — окончательно я выбрал SQLite) — в виде embedded работало без дополнительных установок, насколько я помню.
Здравствуйте, eisernWolf, Вы писали:
W>P.S. Отпишусь-ка я тоже заодно от ветки, а то уже типичный rsdn-овский флейм повалил...
Ага, причем повалил он с готдотнета, что характерно. W>[i]данное сообщение получено с www.gotdotnet.ru
1.1.4 stable SR1 rev. 56
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
1.1.4 stable SR1 rev. 56
