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

[Алёна]

Может не слабо будет еще что-нибудь написать? А?

В процессе, есть три дня свободных, но только опять по справочным системам

[Alf]

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

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

...
К вопросу о распространении, вроде на сайте Microsoft было написано, что Net Framework уже входит в Server 2003 и дальше будет включаться во все новые ОС, к тому же ее можно скачать с их сайта бесплатно и программить прямо в ней (в блокноте   ), я пробовал - "Hello World" написать получилось - т.е. можно писать софт с использованием бесплатного компилятора от Microsoft - неужели такое бывает !
Если я что-то недопонял, поправьте, пожалуйста.

Распространение .NET Framework - не проблема; разумеется, что приложение без проблем запустится на компьютере с установленным NET Framework. Единственное препятствие тут - изрядный объем этого продукта.
Меня интересует другой вариант - создать небольшой дистрибутив, который содержит только все действительно необходимое для работы приложения. Вот этого я пока не нашел. Хотя, следует признаться, искал не особенно тщательно. Было бы заманчиво иметь возможность создавать дистрибутив размером не более единиц мегабайт, чтобы можно было передавать его по почте.

[Ilia]

Alf, учиться! учиться! и учиться! Это я про себя .

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

Благодарные читатели будут только рады новой информации .

[Dimyan]

Alf, прочитал полностью за раз последнюю твою статью -Нормализация реляционных баз данных (я не в первый раз ее читаю, но все как-то целиком не удавалось, все по частям, а это плохо для усвоения, теперь прочитал за раз и полностью), хотел поблагодорить ОЧЕНЬ интересно, НО!!! (ИМХО) довольно сложно написано для начинающих, у меня в принцепе (после четвертого прочтения ) вопросов не возникло, но доходило все довольно долго.  А в общем статья мне понравилась, я бы ее назвал практико - теоретической

P.S.: Серезно подсел изучением литиратуры по БД, я даже и предположить не мог что это так интересно, читаю неотрывно (пока теорию), похоже я нашол свое призвание
Прочитал (ни когда с монитора так много не читал) "ОСНОВЫ ПРОЕКТИРОВАНИЯ РЕЛЯЦИОННЫХ БАЗ ДАННЫХ" В.В. Кириллов. Сейчас приступил к "Основы современных баз данных" С.Д. Кузнецов

[Alf]

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

[Dimyan]

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

[Dimyan]

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

[sk]

Добрый день, Альф!
я - скажем так, программист-"переходник" с VisualFoxPro 6-8 на С-шарп.
так уж заведено судьбой, что переходя на новую работу, мы получаем новых начальников и новые "стандарты предприятия"

в процессе обучения шарп+АДО, у меня возникли некоторые вопросы, о том, на сколько реально использовать в качестве НЕ_SQL_базы базы данных Фокса, файлов .dbc ?
во всех примерах в книгах в качестве примера используется ТОЛЬКО Ацесс либо SQL-2000 (MSDE).

известны ли случаи работы ADO с таблицами VFP?

[Alf]

Добрый день, Альф!

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

я - скажем так, программист-"переходник" с VisualFoxPro 6-8 на С-шарп.

Поздравляю  
Я не сторонник Fox и подобных систем и считаю, что они создают больше проблем, чем решают.

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

В данном случае судьба преподнесла подарок. Если бы пришлось наоборот переходить с C# на FoxPro, было бы куда горестнее.
Обычно за программистами на Fox со стажем тянется хвост старых наработок, которые выбросить жалко, а продолжать сложно. А тут подвернулся шанс разом покончить с ними.

в процессе обучения шарп+АДО, у меня возникли некоторые вопросы, о том, на сколько реально использовать в качестве НЕ_SQL_базы базы данных Фокса, файлов .dbc ?
во всех примерах в книгах в качестве примера используется ТОЛЬКО Ацесс либо SQL-2000 (MSDE).
известны ли случаи работы ADO с таблицами VFP?

Вот тут сразу следует определиться, идет ли речь об ADO или же об ADO.NET?

Если об ADO.NET, что логичнее в среде .NET, то вынужден разочаровать, ответ отрицательный. В статье "Архитектура ADO.NET" в разделе "Провайдеры Данных" я привел перечень провайдеров OLE DB, с которыми в настоящий момент может работать ADO.NET. OLE DB Provider for ODBC (MSDASQL) в их число, к сожалению, не входит.

А вот если попробовать использовать старый добрый ADO, то я не вижу причин, почему бы и не использовать программу на C# совместно с таблицами VFP. Хоть ADO сейчас и не в моде, тем не менее вполне корректно работает с источниками данных ODBC. При стыковке ADO и C# тоже вряд ли возникнут проблемы.

Хотел попробовать привести работающий пример, но на моем домашнем компьютере почему-то при попытке обращения к ODBC-драйверу Visual FoxPro вылетает ошибка (хотя с отдельными таблицами DBF работает корректно). Возможно, следует обновить драйвер. Завтра попробую еще на работе проделать то же самое, на работе я ставил больше всяких патчей на систему.

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

[sk]

Очень рад за быстрый ответ, Альф!

После прочтения Ваших статей (кстати, спасибо за них), а тем более после того, как прочитал твои посты в форуме, у меня сложилось впечатление, что этот человек не только специалист, но и... как бы это сказать по-точнее... человек обстоятельный, уравновешенный, дипломат. а тут такие выпады в сторону старика фокса!  поосторожнее бы...
имхо, выбор средства разработки, это как выбор из какой "посуды" пить. можно и пивко потягивать из бокала для мартини   и рассуждать о том, зачем на свете есть пивные бокалы   фокс был, есть, и по словам Майкрософта одним из лучших СПЕЦИАЛИЗИРОВАННЫХ языков для работы с БД. конечно, на фоксе мультимедийное приложение не напишешь... можно очень много и долго сломать копья в этой разборке ("каждый кулик свое болото хвалит"). этим я конечно заниматься не буду. хотя...

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

После выбора "Connection to database..." получил список доступных провайдеров и... обнаружил следующую строку "Microsoft OLE DB Provider for Visual FoxPro". ну а далее, указание базы (или таблицы), Share Exclusive...
и через пару минут имел грид с данными из базы данных.

но тут есть несколько "непонятных неудобств":
1. не понятно (пока для меня) поведение такой базы при удалении записи. фокс не удаляет записи, а *помечает* их на удаление. т.е. удаленная запись *физически* еще есть. как ее удалить с шарпа "навсегда" :?:
2. как происходит работа с таблицами, имеющими индексные файлы :?:
3. сама база и таблицы - разные файлы. а не один как в ацезе.

ну а про связь фокс -> ацесс -> шарп... а скромно умолчу...

з.ы.
и пусть я только начинаю изучать шарп+АДО.НЕТ, но все же я обязательно попробую (в скором будующем) использовать в качестве НЕ-СКУЛ базы данных именно Фокс.

[Alf]

Очень рад за быстрый ответ, Альф!

Для того и тема, чтобы авторы могли общаться со своими читателями.

После прочтения Ваших статей (кстати, спасибо за них), а тем более после того, как прочитал твои посты в форуме,

Рад, что статьи понравились, я старался.
Кстати, у нас тут народ простой, в ходу обращение на "ты", предлагаю им и пользоваться в дальнейшем. А то у нас вперемешку то "Ваших статей", то "твои посты"... Как у Стругацких в "Сказке о тройке" - "Нет уж, гражданин хороший, ты мне это бросьте."  

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

Если "этот человек" - я, то спасибо на добром слове.

а тут такие выпады в сторону старика фокса!  поосторожнее бы...

Типа "с виду вроде приличный, но внешность оказалась обманчивой"  
Прошу прощения, если кого обидел, ибо старость я уважаю  
Это я просто со своей колокольни порадовался за человека, которому выпала возможность расстаться с Fox. Не учел, что не для всех подобное расставание может быть легким и желанным.

<skipped> фокс был, есть, и по словам Майкрософта одним из лучших СПЕЦИАЛИЗИРОВАННЫХ языков для работы с БД.

Я бы дорого дал за то, чтобы своими глазами увидеть какое-либо детище Microsoft, которое по их словам не было бы лучшим или хотя бы одним из лучших. Такая вот маленькая, но гордая фирма  
Все это так, но по их же словам в эту категорию попадает и Access, и TransactSQL... При этом ADO - самая продвинутая технология доступа к данным, Visual Basic - самая прогрессивная среда для построения приложений с доступом к базам данных и т.д. Работая с любым инструментом от MS, нужно быть заранее внутренне готовым к тому, что ты выбрал лучшее. И стараться не задавать себе вопрос, как это может быть, чтобы несколько совершенно разных систем умудрялись быть лучшими одновременно.

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

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

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

Нет уж, нет уж, не надо "хотя". "Не буду" - на том и договоримся

<skipped>
После выбора "Connection to database..." получил список доступных провайдеров и... обнаружил следующую строку "Microsoft OLE DB Provider for Visual FoxPro". ну а далее, указание базы (или таблицы), Share Exclusive...
и через пару минут имел грид с данными из базы данных.

У меня такого провайдера в системе нет, увы. Не поставляется он ни с Visual Studio, ни с Windows XP. Видимо, идет в комплекте с FoxPro.
Для работы с .DBF я использовал драйвер ODBC. В .NET такое не пройдет, конечно.

но тут есть несколько "непонятных неудобств":
1. не понятно (пока для меня) поведение такой базы при удалении записи. фокс не удаляет записи, а *помечает* их на удаление. т.е. удаленная запись *физически* еще есть. как ее удалить с шарпа "навсегда" :?:

Насколько я помню, "сборка мусора" в базах Fox - это отдельная операция, которую приходится делать время от времени по мере разбухания файлов. Не помню деталей, но думаю, что в принципе можно сделать это из C# через COM.

2. как происходит работа с таблицами, имеющими индексные файлы :?:

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

3. сама база и таблицы - разные файлы. а не один как в ацезе.

А разве это не типично для Fox? На мой взгляд, одна из самых его неприятных особенностей.

ну а про связь фокс -> ацесс -> шарп... а скромно умолчу...

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

з.ы.
и пусть я только начинаю изучать шарп+АДО.НЕТ, но все же я обязательно попробую (в скором будующем) использовать в качестве НЕ-СКУЛ базы данных именно Фокс.

А вот этого противопоставления Fox-SQL я так и не понял. Разве Fox не является реляционной базой данных (с некоторыми оговорками, конечно)? Ну или хотя бы реляционно-ориентированной, скажем так... Или для запросов к базе Fox не используется SQL? Откуда взялось "НЕ"?

[sk]

Здорова дружище, Альф! (это я так после прочтения Стругацких)

действительно не охота ввязываться в полемику о том, какая платформа разработки лучше. но вот к вопросу о том, какие есть приложения на фоксе могу сказать: принимал участие в разработке и внедрении комплекса бухучета, который работает на 17-ти раб.станциях в режиме файлового (!) сервера с использованием терминального доступа (Citrix MF XP, или Win2003). и я таки хочу сказать, что все очень даже было прилично и по скорости и по надежности. тут от "ручек" программистов очень многое зависит.

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

а вопрос об использовании индексов при работе с базами данных очень и очень важный. ему стоило бы уделить как можно больше внимания. никто не будет возражать, что правильно и грамотно составленное индексное выражение  может в *разы* ускорить выполнение запроса.  в фоксе работа с индексами была очень проста и результативна. тут и оптимизация по Ричмор была. как это можно применить в АДО.НЕТ? есть ли варианты использовать индексы как при SQl-соединении (на скул-сервер), так и при OleDB | Odbc (локальные БД)? какие базы данных НАИБОЛЕЕ предпочтительны (скорость, надежность) при работе с *локально* рассположенной БД? (Ацесс, Фокс и т.д.)?
 
и кстати, если движок .DBC файла через ОлеДБ может работать с индексными выражениями также как и в родном фоксе? то - ВАУ! запрос по локальной таблице в пару сотен тысяч записей будет вылетать "на ура"! или я не прав? а какова скорость выполнения такого запроса на ацессовских базах?
ведь не под каждое ТЗ необходимо "сооружать" SQL-сервер! есть задачи, ктр. могут спокойненько крутиться на одной машине, но (!) быть достаточно требовательными к производительности.

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

з.ы.
ну тут скорее всего сработал наш "локальный" сленг    имелось ввиду, что в качестве источника хранения информации на локальном компьютере я попробую использовать базы FoxPro - .DBC ну а "скул"-базы - это конечно SQL-2000 | MSDE и т.д.

[Alf]

<skipped>
действительно не охота ввязываться в полемику о том, какая платформа разработки лучше. но вот к вопросу о том, какие есть приложения на фоксе могу сказать: принимал участие в разработке и внедрении комплекса бухучета, который работает на 17-ти раб.станциях в режиме файлового (!) сервера с использованием терминального доступа (Citrix MF XP, или Win2003). и я таки хочу сказать, что все очень даже было прилично и по скорости и по надежности. тут от "ручек" программистов очень многое зависит.

К сожалению, бухучетом и складом приложения баз данных не ограничиваются (а может, и к счастью для меня), хотя они, наверное, наиболее востребованы сегодня малым бизнесом. А терминальный сервер не есть распределенное приложение, а скорее попытка эмулировать мэйнфрейм малыми затратами. Конечно, у Fox есть своя ниша, в которой он существует и может существовать еще долго. Как правило, это интерактивные системы с несложной обработкой данных (вроде бухгалтерии с ее четырьмя действиями арифметики), небольшими объемами данных (до миллиона записей), ограниченным числом пользователей (17 - это отнюдь не корпоративный уровень, а зачастую и этого порога трудно достичь) и некритичные к времени отклика (реакция оператора все равно не мгновенна). За пределами этой области никакие ручки не спасут.

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

Если речь о моей статье, то не вижу ни малейшего повода для корректировки. Во-первых, статья ориентирована на читателя, который установил Visual Studio.NET на компьютер под управлением одной из последних версий Windows (2000 либо XP). Большинство моих читателей наверняка не найдут в своей системе провайдера OLE DB для FoxPro и будут только сбиты с толку.
Во-вторых, не вижу смысла выделять Fox из среды прочих СУБД, драйверы которых не включены с стандартную поставку Win+VS.NET. Завтра мне поступят аналогичные предложения от поклонников Clarion, Paradox, DBase и т.п. (кстати, с ними наверняка будет гораздо итереснее полемизировать о выборе платформы, чем со мной, поскольку системы примерно одного класса), и статья получится бесконечной.
Посему я все же ограничусь стандартным подмножеством, а любителям альтернативных решений придется изучить особенности своих любимых детищ самостоятельно. К счастью, это не столь трудно, поскольку особенностей этих немного, в основном материал моих статей применим и к ним.

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

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

в фоксе работа с индексами была очень проста и результативна. тут и оптимизация по Ричмор была. как это можно применить в АДО.НЕТ?

См. выше. Приложению, работающему чере ADO.NET, весьма мало дела до индексов, это внутреннее дело сервера, который использует индексы для оптимизации выборки. Если для данного запроса имеется адекватно построенный индекс, сервер просто гораздо быстрее произведет выборку, и соответственно приложение быстрее получит результат запроса. На логике прикладной программы это никак не скажется.

есть ли варианты использовать индексы как при SQl-соединении (на скул-сервер), так и при OleDB | Odbc (локальные БД)?

Несколько некорректный вопрос. OLE DB, ODBC, ADO, ADO.NET - это всего лишь API доступа к данным, а вовсе не СУБД. Для доступа как к SQL-серверу, так и к локальной БД нужно воспользоваться одним из них, причем у каждого есть как достоинства, так и недостатки, как всегда, следует искать компромисс.
Насчет вариантов использования индексов опять же ответ дан выше.

какие базы данных НАИБОЛЕЕ предпочтительны (скорость, надежность) при работе с *локально* рассположенной БД? (Ацесс, Фокс и т.д.)?

Это опять же вопрос из разряда "кто кого поборет - слон или кит", который мы вроде как уже договорились закрыть. Могу только сказать, что, например, в Microsoft Exchange Server 5.5 (с последующими версиями не работал, не в курсе) почтовые ящики клиентов, доски объявлений, очереди документов и т.п. выполнены на основе ядра Microsoft Jet, на котором базируется и Access (по сути, Access - вовсе не СУБД, а всего лишь клиентская оболочка для интерактивной работы с базами Jet). Думаю, этот выбор сделан неспроста, ненадежная СУБД вряд ли была бы выбрана в качестве основы для почтового сервера корпоративного уровня.
Аналогичные коммерческие продукты на базе Fox мне не попадались.

<skipped>
а какова скорость выполнения такого запроса на ацессовских базах?
ведь не под каждое ТЗ необходимо "сооружать" SQL-сервер! есть задачи, ктр. могут спокойненько крутиться на одной машине, но (!) быть достаточно требовательными к производительности.

"Такой запрос" - это абстракция. Очень многое зависит от типа данных в запросе, построения индекса и т.д. Если уточнить задачу, могу проверить на реальных данных. У меня есть одна из баз .MDB размером 1.3 Гб, можно попробовать поискать в ней что-нибудь.
Кстати, явное ограничение на размер баз Access мне не попадалось, но начинались проблемы при объемах более 2 Гб. Так что рекомендую иметь в виду при выборе СУБД для приличных объемов данных.
Кстати-2 (по поводу "сооружения" сервера): как одно из CASE-средств для проектирования софта я использую AllFusion Component Modeler (бывший Paradigm Plus). Так вот, при его инсталляции автоматически устанавливается MSDE, и вся информация о создаваемых пользователем объектах хранится именно в нем. А ведь делала сей продукт фирма Computer Associates, которая в свое время располагала собственной СУБД настольного класса Clipper. Конечно же, это не догма, но все же присматриваться к опыту старших коллег тоже не лишне. По крайней мере, прецедент есть.

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

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

[sk]

Добрый день, Альф!

у меня вопросы, ну прям как у Лермонтова: "...смешались в кучу: кони, люди..." как говорит один мой знакомый: "чтобы правильно задать вопрос, надо знать половину ответа на него"...
дело в том, что это мой первый опыт интерактивного общения на тему как доступа к данным с использованием технологий АДО.НЕТ, так и организации/администрированию *серверных* БД. ну а если подвернулась возможность спросить у знающего человека, то и спрашиваешь ВСЕ что тебя интересует и не ограничиваешь себя рамками открытой для обсуждения темы. вот отсюда и каша в вопросах.

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

буду рад нашим встречам на форумах!
Сергей Кузьменко, Мелитополь, Украина.

[Alf]

Приветствую, sk.

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

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

Так что welcome!

[Natalie]

Прошу прощения за то, что вмешиваюсь в разговор, не сильна я в FoxPro...
В данный момент имею представление о том как создать базу данных средней сложности на Access и SQL Serv. Так вот, в связи с этим вопрос к sk: "Как отслеживается целостность базы данных в FoxPro?"

[sk]

Добрый день, Натали!
да собственно, к чему извинения! это же форум не для двух людей, а как бы наоборот!

к вопросу о отслеживании целостности данных на фоксе.
http://forum.foxclub.ru/read.php?f=5&i=64667&t=64667&v=f
или вот еще
http://forum.foxclub.ru/read.php?f=5&i=64731&t=64702#reply_64731
тут очень интересный пост от "Сергей" по переносу фокса на СКУЛ-сервер

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

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

[Natalie]

Поздравляю с регистрацией, sk.
Спасибо за ссылки, хотя вопрос не принципиальный, а больше просто из любопытства...
Чем смогу.. всегда...

[Kuzmich]

Alf, что-то давно нет статей по БД Тема очень интересна, думаю не только мне, тут нашел как использовать ADO .NET в MFC. Думаю ADO .NET самый универсальный способ работы с БД, хотя не проверял (как раз счас этим занимаюсь).

[Alf]

Alf, что-то давно нет статей по БД Тема очень интересна, думаю не только мне,

Сейчас оформляю очередную статью, через несколько дней опубликую.

тут нашел как использовать ADO .NET в MFC.

Честно говоря, не понял смысла в смешивании ADO.NET и MFC. Если проект пишется заново, то более разумно было бы создавать его весь как managed application, а если производится косметический ремонт старого проекта, то и ADO вполне подойдет.

Думаю ADO .NET самый универсальный способ работы с БД, хотя не проверял (как раз счас этим занимаюсь).

А в чем состоит проверка, по каким критериям и каким образом проверяешь?

[Kuzmich]

Сейчас оформляю очередную статью, через несколько дней опубликую.

Замечательно! Ждем.

Честно говоря, не понял смысла в смешивании ADO.NET и MFC. Если проект пишется заново, то более разумно было бы создавать его весь как managed application, а если производится косметический ремонт старого проекта, то и ADO вполне подойдет.

Если честно, мне непонятен смысл managed application и unmanaged application, так что на вопрос о смысле использования я ответить несмогу. Просто на данный момент ситуация такая: кодю на VS с использованием MFC и приятно было найти способ использования ADO.NET в MFC.

А в чем состоит проверка, по каким критериям и каким образом проверяешь?

Стоит такая задача: сделать соединение с БД mySQL, Access, Interbase, до использования Interbase я делал коннект через ODBC, но для интербэйза бесплатный ODBC драйвер непонимает поле типа Date. Для ODBC есть еще один минус его нужно настраивать. В идеале было бы таскать за собой одну дллку, типа gds32.dll (для Interbase) а в программах использовать для всех БД одинаковые классы типа CRecordset и CDatabase, но кажется это фантастика
Для работы Ado.Net нужен Framework, а он стоит не везде...
Можно конечно работать с БД напрямую, используя C, написать например свои обертки для mySQL и Interbase, но чета так ломает это делать.....

[Anonymous]

Один мой знакомый покупал техническую литературу по следующему признаку - в книге должна быть полезная для него инфа, хоть на страничку.
Эти статьи, приблизительно похожи на описанный случай.
Но кое-что не понравилось. FAT - он и в Африке FAT, а не ТРФ.
А вот эти все ЯОД, ЯМД засоряют статью, так как статья это не собственный научный труд, а работа  с большим количеством переработанной информации.
Почему-то ADO не было переведено.
<b>Alf</b> А вообще неплохо

[Sla]

Предыдущее было мое

[Alf]

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

Весьма благоразумно, многие так делают.

...А вот эти все ЯОД, ЯМД засоряют статью, так как статья это не собственный научный труд...

Не совсем понял идею. А если, к примеру, я возьму за основу изложения статью голландца, того же Дейкстры, мне голландскими терминами следует оперировать? А не дай бог японскую - иероглифами щеголять?
Термины ЯОД и ЯМД - отнюдь не мое изобретение, им уже почти полвека. И мне не кажется целесообразным заменять языки "лэнгвиджами" при наличии устоявшегося русскоязычного термина. Равно как предпочитаю разрабатывать программы, а не "девелопить", отлаживать, а не "дебагить", и исправлять найденные ошибки, а не "фиксить баги".

Почему-то ADO не было переведено.

Я даже могу пролить свет на тайну, почему именно. Имена собственные, в частности торговые марки, я по мере возможности стараюсь оставлять в неприкосновенности, давая при необходимости расшифровку. Вы можете найти массу примеров этому. Например, Microsoft Windows не превратились в моем изложении в "Маленькие Мягкие Окна", как следовало бы ожидать согласно данной логике.
Аналогично и с ADO, поскольку это название конкретного программного продукта (ну или семейства продуктов, если уж быть совсем точным). Вот вы много АДОв знаете? Я - нет. А вот Языков Определения Данных, к примеру, повидать довелось (хоть и не десятками, конечно).

<b>Alf</b> А вообще неплохо

Ну так старался ведь...

[oops]

Раньше программировал на VC++  и о дот нете слышал только название. Но время не стоит  на месте надо расти и развиватся перехожу на С#.

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

Может этот вопрос уже фигурировал в теме тогда извеняюсь (читал тока первую страницу)

[Anonymous]

Не совсем понял идею. А если, к примеру, я возьму за основу изложения статью голландца, того же Дейкстры, мне голландскими терминами следует оперировать? А не дай бог японскую - иероглифами щеголять?
Термины ЯОД и ЯМД - отнюдь не мое изобретение, им уже почти полвека. И мне не кажется целесообразным заменять языки "лэнгвиджами" при наличии устоявшегося русскоязычного термина. Равно как предпочитаю разрабатывать программы, а не "девелопить", отлаживать, а не "дебагить", и исправлять найденные ошибки, а не "фиксить баги".

Да интересное заверение. :?


Если чесно это первая статья в которой фигурирует такая обривиатура .[/quote]

[Alf]

Раньше программировал на VC++  и о дот нете слышал только название.

Не совсем корректное противопоставление, ибо С++ продолжает здравствовать и на платформе .NET.

<skipped>
Чего я не вижу в статьях по ADO NET так это того как получить доступ к таблице из программы напрямую, везде пишут что то вроде для изменения значений в полях достаточно связать с DataGrid.

Пока не видите. До доступа к таблицам доберемся в свое время. Не такая простая вещь ADO.NET, чтобы в паре-тройке небольших статей дать исчерпывающий обзор методов работы с данными.

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

Эгоисты, однозначно  
А если серьезно, то скоро мы эти вопросы рассмотрим. Не в следующей статье, поскольку на очереди у нас рассмотрение объекта Command, но во одной из ближайших непременно.

[Alf]

Да интересное заверение. :?

Если чесно это первая статья в которой фигурирует такая обривиатура .

Это заверение не менее любопытно. Помимо этого, довольно тенденциозно. Лично я бы в подобном случае написал "первая известная мне статья... (далее по тексту)". Допуская тем самым хотя бы в мыслях, что мне может быть известно и не все на свете, и есть источники, которых я не читал.

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

Неужто перевернули массу материала по базам данных и не встретили подобной аббревиатуры? Конечно, я не имею в виду ныне печально известные издания из серии "освой самостоятельно за 5 минут и забудь через час". Но взять тех же Дейта, Кодда, Ульмана, Мартина... Мейера, в конце концов. Не верю. Скорее всего, невнимательно читали.

Не поленился нажать несколько кнопок, и Яндекс выдал несколько сот страниц с результатами поиска. В частности, вот одна из найденных книг: Краткое практическое руководство разработчика информационных систем на базе СУБД Oracle. А.И. Власов, С.Л. Лыткин и др.

Выдержка из книги:

2.1.2. Понятие языка определения данных (ЯОД - DBTG)

Язык - средство, при помощи которого определяется структура данных или схема, а также происходит запоминание данных и манипуляция ими. Язык, которым определяется схема, называется языком определения данных (ЯОД),а язык, используемый для запоминания данных и манипуляции ими, называется языком манипуляции данными (ЯМД).

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

Надеюсь, убедил?

[Alf]

Пардон, забыл привести ссылку на книгу, из которой приведена цитата.
Исправляюсь: http://www.interface.ru/fset.asp?Url=/oracle/dever3.htm

[Sla]

Когда я задел тему про аббревиатуру, то я хотел сказать, что пожайлуста - переводите, но давайте и родную. Поэтому и привел пример про FAT.
Думаю что и гость хотел именно так сказать
Эти статьи читают люди которые могут ничего не понимать в английском, или понимать на школьном уровне, или только учатся.
Ведь с AODом нормально получилось - и перевод, и объснение.
Когда послушаешь программеров, знающих немецкий, врите, врителн, вхиле, вхере, хочется равть и метать, хотя знаешь, что  их уровень выше твоего.
девелопить, фиксить - это для крутости, чтобы ламеры ничего не поняли.

Объявление:  требуется специалист, знающий ШПУХ, я ломал голову долго, а потом дико смеялся - ШПУКС он и в Африке HP Unix
Какую-то больную тему я затронул, может и отвлекает она, извините