Цикл статей по базам данных

[Alf]

MS Access я планирую применять для демо-версий программ, работающих с сервером MS SQL. Думаю, что такую телегу эта кошка потянет.

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

[FoxVID]

"Серверные решения" (Paradox, InterBase, ...)

По-моему, Paradox ни каким боком не вписывается в серверные решения. Все решения здесь будут только на стороне клиента.

[FoxVID]

как бы не пришлось для демонстрации создавать совершенно другую версию программы

Да, придется многое ограничить и некоторые функции отключить.   Но другого выхода я пока не нашел. Разве что демонстрация на своем компьютере

[Alf]

По-моему, Paradox ни каким боком не вписывается в серверные решения. Все решения здесь будут только на стороне клиента.

Разумеется, под "сервером" в данном случае подразумевается вовсе не физически выделенный под эту задачу компьютер; вполне возможно, что это будет сервер COM, динамическая библиотека для связи по ODBC или какой-то фирменный интерфейс от Borland. Главное в данном случае то, что код для доступа к данным непосредственно не присутствует в клиентском приложении. Так что и я в своем изложении не буду делать разницы, скажем, между выделенным сервером SQL-2000 или локальной базой Access, если в контексте решаемой задачи эта разница несущественна. И то, и другое для клиентского приложения - сервер.

[Alf]

Еще вопрос к читателям будущих статей.
Сейчас мы подобрались к самым что ни на есть практическим вопросам - разбору ADO.NET, и прозвучали пожелания включать побольше примеров. Примеры, естественно, я включал и буду включать работающие, готовые к компиляции и выполнению с минимальными усилиями.
Думаю, ни для кого не секрет, что в среде Visual Studio .NET имеется несколько "мастеров", призванных облегчить труд программиста за счет автоматизации некоторых рутинных процессов.
Собственно, вопрос: включать ли в статьи примеры по работе с "мастерами", или ограничиться только созданием объектов в коде? Возможно, графическая оболочка есть не у всех, и они работают из командной строки. Или же кому-то интереснее разбирать написанные вручную программы.
Свое мнение высказывайте здесь. Если мнения разойдутся, сделаю голосование.

[Never]

Alf, начал прекрасно. С удовольствием прочитала первые две статьи. Про АДО только распечатала- почитаю, как приду с работы. Чего хочется сказать.
  Чем нехороши для обучения форумы и обращения к крутым спецам: нельзя отследить разрыв в классе между спрашивающим и отвечающим. То, что спец порой считает само собой разумеющимся, для кого-то темный лес, или он что-то слышал, или он как в том эстрадном номере "тут играйте- тут не играйте, а тут рыбу заворачивали", т.е. имеет мозаичные понятия. Если отвечающий отвечает со своего уровня, он не объясняя использует понятия, незнакомые спрашивающему. Результат- усиление мозаичности знаний за счет того, что он вынужден лезть и выяснять а что за термин был употреблен на странице n при объяснения вопроса m, без которого я не въеду в то, что мне ответили. При этом возможно часть информации, расположенная где-то между двумя терминами и подразумевающаяся как ясная сама по себе метром выпадает из точки зрения чайника (ну, менее знающего спеца, скажем так ). Этим грешили мои учителя, следовательно кашу в голове получаем ту еще!
        Ты в первых статьях ИМХО избежал этой проблемы. Изложил материал стройно и системно. Т.ч несмотря на то, что вещи, которые вошли во вторую статью я знаю, прочитала не без пользы для себя- лучше отструктурировала то, что уже было в голове.
       Поэтому. На призывы не жевать не поддавайся!
В конце концов можно построить статью так, чтобы были довольны все. Правда это требует некоторого напряжения от пишушего, когда в одном пространстве сочетать разные уровни сложности. По крайней мере можно писать для среднего уровня, но давая разжеванные объяснения для чайников. Что-то типа подхода, использующегося для учебников: вначале- проще, по мере продвижения к концу- сложнее, только уложен должен быть этот принцип в одну статью.
   в общем, удачи, Alf, начало прекрасное!!!    

[Alf]

Never, спасибо за поддержку!
Для таких благодарных читателей уж сам бог велел постараться  

[Dimyan]

Alf,  я тоже блогодарный читатель
Великолепные статьи, я даже себе папочку завел и вней подшивку твоих распечатаных статей делаю.
я в БД не силен, ну т.е. писал когдато для техникума своего в Access базы для учебной части и отдела кадров (говорят ими до сих пор пользуются), но теоретической подготовки у меня нет, все так методом проб и ошибок. Так что твои статьи читаю с упоением, все великолепно, понятно и доступно.
Я очень рад.

Одно замечание: расшифровывай  пожалуйста сокращения не только на русском но и на английском.

[Ilia]

Alf, спасибо за ADO.NET.
Помниться, я спрашивал, какую технологию использовать и Alf мне все растолковал с пояснениями, за что ему огромное спасибо.
Сессия закончиться, протрезвею    и обязательно начну изучение ADO.NET и именно с "Технологии и средства доступа к реляционным базам данных. ADO.NET"

[Гром]

Альф - спасибо.

Остальные авторы - равняйтесь.

[Alf]

Dimyan, Ilia, Гром,
я... это... типа, оправдать попытаюсь...  

А если серьезно - ждите скоро новые материалы. На подходе перевод интереснейшей статьи Дейкстры "Смиренный программист" (самая классическая классика), подобран материал для следующей статьи по ADO.NET, заодно продумываю очередную по теории... Так что готовьте папки потолще, смазывайте дыроколы, скоро пригодятся

[Антон (LogRus)]

... Так что готовьте папки потолще, смазывайте дыроколы, скоро пригодятся

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

[Dimyan]

LogRus,  не повезло
у меня много статей с Весельчака У распечатано (не люблю с монитора читать) и моя супруга зная как я ими дорожу недавно даже специальное место в шкафчике мне под них отвела!  8)

[Never]

Dimyan, я тоже не люблю с монитора. А в распечатках просто тону! Надеюсь после того как куплю стол с ящиками, распихаю это все, будет малость полегче.

[????]

Не голосовал, т.к. "отл" поставить не могу, а "хорошо" с плюсом нет Если надо, могу дать pdf плакат "ADO.NET and System.Xml Classes in the .NET Framework" от MS. Нашел его на их сайте, где - не помню файл назывался ADO.NE_System_XML_Classes_X0910398pst_a_OL.pdf
Формат:
37,47х68,58 cm
pdf 1.4 (acrobat 5.0)
рамер 523 Кб

кому инт, ышыте по мылу b.i(at)date.by, а еще лучше на ms и кидайте ссылку, т.к. там было много постеров (у меня 10разных)

[Dimyan]

вопрос по курсу (перечитал еще раз третью статью):
Нужно ли для профессионального использования ADO.NET учить COM?

[Alf]

вопрос по курсу (перечитал еще раз третью статью):
Нужно ли для профессионального использования ADO.NET учить COM?

Отличный вопрос, однозначным ответом не отделаешься... Попробую чуть подробнее.
1. Платформа .NET сделала в принципе возможным программирование без использования COM, предоставив альтернативный механизм повторного использования кода в "управляемых сборках" (к своему стыду признаюсь, что я до сих пор не знаю названия этого механизма, если его только уже как-то успели назвать). С этой точки зрения ответ - НЕТ.
2. Предшествующие примерно 10 лет программирования в среде Windows прошли под знаком технологии, которая по мере взросления многократно меняла имена: OLE/COM/ActiveX/COM+/DCOM... (ничего не забыл?), не меняя при этом своей сути коренным образом. Создан огромный задел, игнорировать который - просто легкомыслие и расточительство. Имеется бессчетное количество готовых к употреблени элементов управления ActiveX и серверов COM, причем неизвестно, когда появятся аналогичные им по функциональности модули .NET. Поэтому профессионал на сегодняшний день не может позволить себе обойтись без знания COM. С этой точки зрения ответ - ДА.
3. В статье я упоминал, что на данный момент имеется полностью управляемый провайдер только для MS SQL Server 7.0 и выше. Работа со всеми другими источниками данных ведется через механизм OLE DB, который базируется на COM.

Вообще ситуация с .NET мне очень напоминает ту, которая сложилась в момент выхода в свет Windows 95. Оптимисты восторженно кричали, что наконец-то получили 32-разрядную среду, которая решит все проблемы. А пессимисты справедливо указывали, что отовсюду торчат уши 16-разрядного кода, вокруг которого на скорую руку слеплена 32-разрядная оболочка. И изживали эти антикварные модули мы потом еще очень долго (кто программирует не первый год, должен помнить, как мучительно шел этот процесс).

Резюме: в принципе, без знания COM программировать можно, особенно если ограничиться только задачами вокруг ADO.NET. Но владение механизмами COM позволяет писать программы быстрее и лучшего качества. Да и что, собственно, это значит - "профессиональное использование ADO.NET"? Ведь получить данные из хранилища - это обычно не самоцель, а скорее только полдела. Как правило, с ними нужно что-то сделать: составить отчет, построить диаграммы или графики, отправить по электронной почте, опубликовать на Web-сайте... Вот тут-то знание COM и сослужит добрую службу.
Надеюсь, не запутал еще сильнее?  

[Dimyan]

Alf,  и не надейся, запутал в конец!  
Но всеже задам еще вопрос (или спрошу совет):
Если всеже учить COM то (я понимаю что однозначного ответа наверно нет, но всеже) что следует овладеть вперед COM или ADO.Net

[Alf]

Alf,  и не надейся, запутал в конец!  
Но всеже задам еще вопрос (или спрошу совет):
Если всеже учить COM то (я понимаю что однозначного ответа наверно нет, но всеже) что следует овладеть вперед COM или ADO.Net

Видишь ли, COM никак не опирается на ADO.NET, а ADO.NET, в свою очередь, делает вид, что не знает про COM (хотя и использует его внутри себя, но пользователям это все равно не видно). Поэтому изучать их вполне можно независимо друг от друга. Но вообще знание COM на сегодняшний день обязательно для профессионала (и еще долго будет), поэтому, если до сих пор не ознакомился, приступай не откладывая.
Лично мне нравится книга Дейла Роджерсона "Основы COM", изд-во "Microsoft Press", русская редакция. Поищи по магазинам, мне еще попадалась в продаже.

[Dobro]

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

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

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

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

По поводу статьи об ADO.NET:
Ты и сам понимаешь, что это была статья, которая явно опережает время, если говорить о последовательно изложении тематики БД. Поэтому, я бы не включал ее в этот цикл статей. На крайний случай, если людям не втерпежь, можно было бы завести параллельную ветку по практическим технологиям использования СУБД. Хотя IMHO изучать ADO.NET, не познакомившись хотя бы поверхностно c SQL, ODBC, COM, OLEDB и ADO, не самая лучшая идея.

[Dezz]

ADO работает с IB через odbc, а это полный мумий троль.

Э... Устареваете, батенька. Уже давно есть OLEdb-провайдер для Interbase/FireBird.

[Never]

Я так понимаю, что в данной теме можно заказывать статьи не только Альфу?

[Гром]

Never, в этом форуме, но не в этой теме, тема - конкретно для Альфа и статей по Адо.

[Never]

Ага, я уже посмотрела... Простите за тормоза- никак не могу сегодня проснуться :oops:

[Dimyan]

Alf, прочитал последний урок, сделал проктическую часть, все получилось, давно так не радовался своим успехам  
Материал понятен, правда иногда хочется хотябы чуточку побольше теории. Хотел задать вопрос:
может я тораплю события, но меня рвет от любопытства
Я уже наслышан о несовершенстве баз Accessa и прекрасно понимаю что пример на них мы рассматриваем только для обучения, а вот какие же всетаки лучше базы или наверное правильние хранилища данных? использовать???
И еще:
Alf, очень очень хочется узнать как можно подробние какой же всетаки объекта Connection предпочтительнее OleDbConnection или SqlConnection?
Хотя я конечно понимаю, что выбор ведется в зависимости от задачи, но опять же (хотябы обобщенно) для какой задачи какой предпочтительние?

[Never]

Alf, поподробней про домены, пожалуйста: с чем едят, как можно и нужно использовать.

[Alf]

...Я уже наслышан о несовершенстве баз Accessa...

Вот те и раз... Это от кого слышал-то? От Ларри Эллисона? Или Дэвида Эверарда, к примеру?  
Да ядро Microsoft Jet, на котором построен Access, - практически идеальный вариант для создания всевозможных приложений настольного класса, а при необходимости - и для маленькой рабочей группы из 3-4 компьютеров. Роскошный инструментарий для конструирования таблиц и запросов, создания индексов, встроенная поддержка для начинающих по нормализации таблиц и повышению быстродействия запросов при помощи индексов. Есть простые CASE-средства для графического проектирования базы. Как выяснили на форуме совместными усилиями, параметризованные запросы способны эмулировать хранимые процедуры, как на "настоящих" серверах баз данных.
Простые задачи обработки данных можно решать посредством встроенного Visual Basic for Application, а если задача выходит за рамки его возможностей - всегда можно написать внешнее приложение, которое получает доступ к данным посредством DAO, ODBC, ADO или ADO.NET, - короче, на любой вкус.
К недостаткам ядра Jet я бы отнес отсутствие триггеров, а также весьма рудиментарные средства для организации многопользовательского доступа. Но, к слову сказать, некоторые продукты, претендующие на сегмент SQL-серверов (например, MySQL, Postgres), имеют не менее серьезные изъяны по части функциональности.
Резюме: для своего класса (настольные приложения, очень маленький офис) MS Jet (он же Access) - вполне адекватный инструмент. Может также использоваться для создания макета более серьезной информационной системы (хотя должен заметить, что для этого есть инструменты и получше). Я бы не стал к нему относиться так уж свысока; есть большой спектр применений, где это ядро будет оптимальным.

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

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

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

Нужно знать плюсы и минусы каждой системы и уметь выбрать подходящий менно для данного случая инструмент.
Если ты работаешь над информационной системой корпоративного уровня, то тебе определенно придется поднимать SQL-сервер (и весьма вероятно, что не один). Для этого вполне подойдут, скажем, Oracle И MS SQL Server. Некоторые предпочитают InterBase, Sybase, Informix, Gupta... - в общем, спектр решений весьма широк, и каждое имеет право на жизнь, свою собственную нишу.
Но у таких решений есть обратная сторона: сложная система обычно сложна в обслуживании. SQL-сервер нуждается в администрировании. Если ты ставишь систему в небольшую торговую фирму, где самый продвинутый специалист по компьтерной части - секретарша, кое-как терзающая Word и Excel, долго эта система наверняка не протянет, и ты услышишь очень много нелестных слов в свой адрес, когда она встанет в аккурат при отгрузке большой партии товара или в другой столь же подходящий момент.
В то же время неприхотливое приложение, базирующееся на Access, прекрасно справится с ведением того же небольшого склада (а если база физически размещена на компьютере кладовщика, то ей к тому же будут безразличны регулярные падения сети, нередкие в подобных конторах).
Одним словом, руководствуйся чувством меры и помни принцип Оккама, который предостерегает от излишней сложности.

И еще:
Alf, очень очень хочется узнать как можно подробние какой же всетаки объекта Connection предпочтительнее OleDbConnection или SqlConnection?
Хотя я конечно понимаю, что выбор ведется в зависимости от задачи, но опять же (хотябы обобщенно) для какой задачи какой предпочтительние?

Это ты статью совсем невнимательно читал, я там акцентировал внимание на особенностях этих объектов...  
Ладно, давай пройдемся еще раз, вкратце. SqlConnection разработан специально для работы с Microsoft SQL Server 7 и выше. Ни с каким другим источником данных он работать не будет. Зато он оптимизирован под MS SQL, обеспечивает наивысшую возможную скорость работы и к тому же имеет уникальное свойство PacketSize, которое позволяет минимизировать накладные расходы при передаче данных в сети посредством регулирования размера передаваемых пакетов.
OleDbConnection, как это видно из названия, работает с источником данных посредством интерфейса OLE DB, который построен на основе COM. OLE DB способен работать с множеством различных СУБД, для которых имеется драйвер OLE DB, а также может исользовать соединение через ODBC. В этом состоит его основное отличие от SqlConnection, на этом же основываются плюсы и минусы.
Плюсы: больший выбор источников данных, т.к. OLE DB не ограничивается только MS SQL. Кроме того, возможна миграция с одно платформы на другую, например, с MS SQL на Oracle и обратно, с минимальными переделками кода, а то и вовсе без них.
Минусы: во-первых, большие накладные расходы, т.к. между OleDbConnection и источником данных оказывается еще прослойка в виде OLE DB. Во-вторых, далеко не каждый драйвер OLE DB способен работать с ADO.NET. Например, драйвер для ODBC использвать нельзя. Мой коллега пытался работать с MySQL через ADO.NET и тоже не добился успеха.
Резюме: если твое приложение заведомо будет работать только на MS SQL, можешь использовать SqlConnection, при этом выиграешь в производительности. Если требуется работать на другой платформе или хочешь добиться большей универсальности, используй OleDbConnection, заплатив эффективностью.

[Alf]

Alf, поподробней про домены, пожалуйста: с чем едят, как можно и нужно использовать.

Для начала можно привести грубую аналогию с типами данных в языках программирования. Обычно тип определяет два основных аспекта: какое множество значений может принимать данный объект и  какие операции над ним допустимы. Например, числа с плавающей точкой двойной точности могут принимать значения из определенного диапазона (который очень велик, но все же конечен), и над ними можно выполнять арифметические операции. Логические переменные могут принимать только два значения - "истина" и "ложь", и над ними можно выполнять операции булевой алгебры. Бессмысленно пытаться поделить, скажем, "ложь" на 3.1415927.
В некоторой степени домен для атрибута отношения - то же самое, что и тип для переменной. Домен также задает множество значений, которое может принимать атрибут.
Различие заключается в том, что число, допустим, int, - это абстракция. С его помощью можно считать звезды на небе или, скажем, песчинки на берегу океана - суть операций над числами от этого не изменится.
Базы данных, как правило, строятся не только для хранения некоторых объемов данных; при проектировании базы основная задача - построить модель предметной области, которая наиболее адекватно отражала бы действтельность, не будучи при этом перегруженной второстепенными деталями. Специфика предметной области оказывает свое значение на понятие домена, и оно приобретает некоторую семантическую окраску.
Приведу пример. Допустим, нам поручено сделать справочную систему для пассажиров железнодорожного транспорта. В первую очередь мы должны построить модель расписания и заполнить ее данными.
Расписание состоит из однотипных строк, каждая из которых информирует о номере поезда, дне недели, времени отправления и, допустим, платформе, с которой отправляется поезд.
Итак, мы имеем 4 атрибута:
1. Номер поезда - натуральное число.
2. День недели - пн, вт, ... вс.
3. Время отправления - время суток.
4. Номер платформы - натуральное число.
В первом приближении номер поезда может быть любым натуральным числом. Но, поговорив с начальником станции, мы можем выяснить, что номер поезда никогда не превышает 1000. Итак, домен первого атрибута - номер поезда - это число от 1 до 1000.
День недели может принимать только лишь одно из семи фиксированных значений. Как мы из представим - в текстовом виде или числами от 1 до 7, - особой роли не играет. Главное, что мы знаем, как интерпретировать любое из этих значений.
Время отправления может быть любым временем суток, поскольку поеза отправляются кругллосуточно. поэтому домен для атрибута 3 - время суток - это время от 00:00 до 23:59.
Номер платформы - в принципе натуральное число, но на самом деле оно ограничено реально имеющимися на вокзале платформами. Если их всего 8, то домен для атрибута "Номер платформы" - число от 1 до 8.
Заметим, что при определении важен не только тип величины, представляющей значение атрибута, но и ее семантика. Так, например, и номер поезда, и номер платформы - натуральные числа, но вряд ли в нашей модели имеет смысл их произведение, операция, вполне допустимая для натуральных чисел.
Зачастую определить множество начений атрибута далеко не так просто, как в нашем примитивном случае. Иногда это может быть громоздко, например, если нам для нашей модели потребуется атрибут "станция назначения". Но в принципе проблема может быть решена простым перечислением всех возможных станций, взятых из железнодорожного справочника.
Для атрибутов вроде "фамилия" дело еще сложнее. Мы понимаем, что Иванов - допусимая фамилия, а вот Уеороккйфд - вряд ли. Но как компактно описать правило, определяющее допустимость текстовой строки в качестве фамилии, лично мне неизвестно. В данном случае приходится идти на послабление - объявить, что доменом для данного атрибута является множество допустимых фамилий, и надеяться на здравый смысл того, кто будет заполнять таблицы.
Таким образом, зачастую не представляется возможным определить домен с математической строгостью, и приходится довольствоваться простым описанием (как в случае с фамилией).
Используется информация об ограничениях домена обычно при заведении триггера на добавление строк в таблицу, который может проверить принадлежность вводимого значения к домену (если это возможно) и отбросить строки с недопустимыми значениями атрибутов.

[Never]

Ага теоретически кое-что прояснил, спасибо. Осталась малость: разобраться с практикой

[Dimyan]

Да, согласен теоретически понятно, но очень хочется попробывать понять это в деле, где и зачем понятно, а вот как применить?