Бази данни...

Програмно да се създаде база-данни. Примерен код за достъп - четене/запис в база-данни. Код за търсене, критерии, и т.н.

???

Занимава ли ви се? ;о))


Щирлиц

Бях пробвал нещо подобно - еднофайлова база без никакви екстри, само с криптиране и двайсетина data types - минимален размер и добра скорост на заявка. Ако искаш мога да ти пратя това, което направих тогава, само че е в доста начална фаза. Използвах ADODB и си измислих бинарен формат на файловете. В MSDN има пример как да се направи подобно нещо.
Зарязах го защото не си струва, при големи бази едва ли ще има кой знае каква ефективност, а при по-малки .xml файловете вършат чудесна работа. Освен това на VB подобно нещо може да има само "спортна" стойност

Аз имах впредвид по-стандартна база-данни. Access-ка таблица например, код за създаването и с DAO например, може да спретнем и малък модул за правене на всички тези неща, който да може да се ползва към различни проекти.

Най-често се случва на начинаещите писачи да не се ориентират как най-лесно и точно да направят базата, и аджиба какво да правят, за да пуснат крайна версия на програмата. Например да пуснат като дистрибуция готовото EXE, а то при първия си старт - да си прави базата, и да почва да работи. Умувам сега по модулче, което спретва база, като взема данните за таблиците и полетата от обикновен стринг. Така писача на програмата докато разработва, и му се налага да променя полета и/или таблици - ще може да го прави само с Notepad и еднократно стартиране на програмата, без да я отваря в DataManager-a, и да минава през километричните Wizard-и, които кой знае защо - ги мразя.

Една друга интересна тема е - за обновяването на програмите. Например писача ще обнови версията, ще качи ЕХЕ-то на някой сървър, но вече работещите по света програми трябва да могат да се обновят от този сървър. Това също може да стане на модулче, и само да се закачва към приложенията. С VBprogrammer спретнахме нещо, което мисля за подходящо за малки проекти, но нека и той каже мнение дали да ги пускаме тук.


Щирлиц

Ами идеята за ъпдейта май е по-интересна
То за базите има доста написани тулове.
От вече съществуваща база да се генерира SQL за създаването и е въпрос на няколко кликания с мишката ...

И аз съм писал подобно нещо за Access. При инсталиране на нова версия да се променят полета, индекси и да се зареждат с данни по подразбиране. Само че кодът е за конкретно приложение и не е универсален, но по принцип съм фен на идеята и бих се включил. Все пак, си мисля, че е добре да се помисли и за SQL Server - по-сериозна база е от Access-a.

Е, да. Няма как да се направи универсален код, но при разработването на приложение често се налага да се променя базата, и това със стандартните инструменти става тромаво. Ако бъде изгенериран код, който да се сложи в стартовата процедура на приложението - много лесно може да се коригира таблицата.

Също така има някои несъвместимости с различните бази-данни. Например в едно от приложенията си направих базата с вградения инструмент на VB6 - "Visual Data Manager...", направих я стандартна "Microsoft Access Version 7.0 MDB", и за отварянето и в приложението ползвах "Microsoft DAO 3.6". Всичко добре, и стигам до създаването на дистрибуция. Исках да сложа в инсталационния пакет само ЕХЕ-то, няколкото външни библиотеки, и при първия старт приложението да си прави празна база. Екстра. Изрових от нета готов проект за генериране на VB6 код. Той пък ползва за достъп до MDB-то ADODB, и съответно генерирания VB код също е с ADO. ... Имах три варианта пред мен. Или да променя приложението си да ползва изцяло ADO, или да добавя като референция ADODB, и базата да се създава с ADO, а да се ползва по-нататък с DAO, или да препиша онзи проект от нета с DAO. Е, избрах третия, щото ми беше най-бързо. Дори стана много по-сбит, щото прескочих няколко неща, и направих някои неща по подразбиране без възможност за корекция. Например за Text поле се задава . Сега новия проект генерира спретнат и сбит по редове код с DAO, но разбира се има и условности. Тези неща могат да се направят като модули в отделни файлчета, защото в тях всъщност няма конкретизирани променливи и обекти.

Въпроса с ъпдейтването - също го направих на модул. Ще питам колегата, ако няма претенции към авторски права - ще постна кода тук.


Щирлиц

Сори, при Copy-Paste е изчезнал част от текста, и чак сега видях.

Бях писал, че в спретнатия код за правене на база - за Text съм указал по дефолт "Allow zero lenght = True", щото оная тъпотия, дето ми натвори с ADO - това пък беше обратно, и не се съобрази с "оригинала" в базата, която ми беше шаблон, та после цялата програма не ми работеше. ;о)

За SQL - лошо няма, но за всеки проект си има "големина", която е най-подходяща. За малките проекти аз лично предпочитам да мога да пусна ЕХЕ-то като дистрибуция, и то да тръгва без да крещи разни изисквания като .NET framework, или пък SQL server, или пък разни ненагледни библиотеки, които с Гугъл трябва да ги търсиш. Практически с малко усилия и Фотошоп - може човек да си спретне чудесен интерфейс, който даже и работи, пък колко неща ще свърши програмата - е въпрос на писане. В няколко проекта се отпуснах да ползвам "SmartMenuXP", и вярно, че изглежда по-добре от стандартното меню, но все трябва да се мъкне с дистрибуцията. Досадно е.


Щирлиц

Мисля, че Microsoft не случайно са се потрудили да спишат ADOX като библиотека. Принципно DAO е ok, но не е portable. А ADOX е просто thin wrapper върху определени OLE DB интерфейси (както и самото ADODB) и обещава да работи върху произволни бази, стига да имат читави OLE DB provider-и.

Just my $.02 worth :-))

cheers,
</wqw>


[линк]

Съгласен съм, но просто предлагам тема за размисъл, защото и SQL 2000, и SQL 2005 имат безплатни версии, които вършат доста по-добра работа от Аксес. Аз лично пиша на Аксес от 12 години, но имам горчив опит с една уж малка и проста програмка, но с много данни и Аксеса горкия се затормози здраво.

Разбира се, и бинарна база да си направи човек - пак работа ще си свърши, но имах впредвид база, която да е лесна за изпълнение от всеки начинаещ.

В това отношение с VB6 идва и точно този "Visual Data Manager", с който лесно се прави базата, и отварянето и е като майтап работа. А пък в книги както за начинаещи, така и за напреднали - наблюдавам една тенденция да се покаже основните техники за достъп до бази данни, и предимно се започва с DAO. Затова и аз подхванах така темата, пък и повечето ми проекти са само с DAO.

Да, за голееееми комерсиални проекти, където ще има по 1000 записа на ден - SQL ще е решението. Но не всеки начинаещ се захваща със задача с разтърсваща света сложност. Обикновено се занимават с малки проекти, разни телефонни книги, или списък с МР3-ки. Всичко това става чудесно с DAO, и базата в такъв вариант е съвместима и с всички контроли за генериране и отпечатване на отчети. Например "DataDynamics ActiveReports" е доста добро.

Разбира се който си ги знае тези неща - няма да му е интересно да участва тук в клуба, но този клуб го направихме най-вече за да може да се обменя опит. На който знаещ не са му чаааааааак толкова комерсиални знанията - нека сподели няколко реда код, ще има кой да го прочете. ;о)

...

Та ето какъв "стандарт" си изграждам в приложението си.

Стартова процедура "Sub Main" в модул. В началото на модула се дефинират глобалните променливи, Workspace, Database, и таблиците. В самата процедура Sub Main отварям таблиците за достъп, проверявам дали старта не е след ъпдейт, за да изпълни кода за презареждане, правя проверка за база данни, и ако няма база - стартира процедурата за създаването и, и след това зареждам главната форма, откъдето започва одисеята. В нея вече изпълнението се поема от кода за рефреш на контролите по формата, проверка за размер на екрана, евентуално имам процедура за "смаляване" или "увеличаване" на формите, ако монитора работи на 640х480, или пък е изтресен на 2048х1536... Тогава процедурата за преоразмеряване върши чудесна работа, като разбира се потребителя има право да избира дали да се "уголемяват" формите. Не са точно универсални процедури, справят се със стадартните TextBox, ComboBox, ListBox, Label, CommandButton и евентуално със SmartNetButton например, но ако човек ползва и други контроли - за секунди може да си ги добави към процедурата за преоразмеряване.

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


Щирлиц

Това е доста сериозно начинание. Готов съм да те подкрепя - ще изровя такива неща, които съм писал и ще ги публикувам тук, но според мене трябва да го сложиш в друга тема, за да предизвика по-голям интерес и да я боднеш най-отгоре. Тази тема се казва "бази данни" и започна с доста по-ораничен "scope".

Така е, и темата отгоре засега е "Tips & Tricks". Снощи качих модула за ъпдейтване и направих кратко съдържание на темата, за да се вижда по-добре какво има вътре. Но може новите неща да се пускат в отделни теми, където да може да си тече дискусия за всяко нещо в отделна нишка.


Щирлиц

Идеята много ми допада.Бройте и мен, включвам се. Може да го направим в два варианта - с Ado и с DAO. Идеята структурата да се пише в текстови файл е добра, ама ако разширим функционалността на модулчето няма ли да стане малко сложен синтаксиса на това файлче. Няма ли да е по-лесно модулчето да си има интерфейс за тази цел и да използваме бинарни файлове и UDT структури. Както и да е... това в процеса на разработка. Дайте да дооформим идеята, да я разбием на блокове и да се захващаме за работа. Щирлиц, ти даде идеята, ставай координатор, няма как :-)

Хрумна ми още едно допълнение към идеята. Може в последствие да добавим и възможност за отдалечено администриране на базата. Какво ще кажете...

Няма проблеми.

Бинарни структури - не са добре, щото няма как да ги впишем лесно в кода на програмата.

Ето какво ми се иска:

Базата данни да е описана като текст така
T=Imena
f=Ime, Text, 50
f=Address, Text, 150
f=Phone, Text, 30
T=Firmi
f=Ime, Text, 50
f=Address, Text, 150
f=Deinost, Text, 150
f=........... и т.н.

Този текст може да се вкара вътре в сорса на програмата, и да се коригира само на едно място.

Модула, който създава базата просто трябва да го прочете по редове, което никак не е трудно със Split(), но идеята е да има и втори модул, който при стартиране на приложението да обходи базата, и да провери дали в нея съществуват всички таблици и полета. Просто защото при ъпгрейд на програмата може програмиста да е добавил още някоя таблица и/или поле, и съответно обновеното ЕХЕ трябва да може да "поправи" старата база, като и сложи новите полета, и да продължи да работи.

Вече имам направено приложение, което ми чете готова база, и прави сорс код на VB6 за създаването на същата. Лесно ще може да се промени този код да стане универсален, и да взема данни за базата от такъв текст по-горе. Но преди да се впуснем в писане - може да дообсъдим какъв стандарт ще създадем за този модул.

Щирлиц

Намерих интересно скриптче, което може да ни свърши работа.
Виж това:[линк]
В случая пича дето го е писал само чете таблиците и записва информацията за тях в ХМЛ файл. Хареса ми идеята, защото файла става доста прегледен, а и не е проблем да се редактира с който и да е редактор.

Тук трябва да поставим няколко фундаментални въпроса:

1. Каква е основната цел: да се генерира база (първоначално) или да се правят ъпдейти. Според мене второто е по-интересния проблем. А може просто да си поставим и двете задачи и да търсим решение, което да ги удовлетворява достатъчно добре и двете.

2. Ако изберем целта да правим ъпдейти, има друг въпрос: как ще се прави той? Тук има два подхода:

(1) програмен, т.е. това, което ти предлагаш - имаме описание на новата структура на базата, имаме и една база. Програмата трябва да провери дали структурата на съществуващата база отговаря на описанието и какви са разликите. И според разликите сама да прецени дали да се добави поле или да се махне или да се направи нещо друго. Това, според мене е по-трудния начин и предполага много грешки при изпълнението.

(2) полуавтоматичен, т.е. програмистът описва какво трябва да се направи, а програмата го изпълнява. Ще дам пример: в една предишна фирма имахме такъв код, който беше написан на SQL и беше предназначен само за SQL Server. Там в базата се поддържа една табличка с ено поле - версия. И се пише един SQL скрипт, в който първо се пита дали версията е 0.1 (например). Ако е така се изпълняват поредица от SQL команди, след което версията се ъпдейтва на 0.2. На следващата стъпка се пита дали версията е 0.2 и се изпълнява друга серия от команди. По този начин всяка една стъпка от развитието на базата е описана и можеш да направиш ъпгрейд от която и да е версия към най-последната. Освен това с него можеш да изпълниш и заявки за предварително зареждане с данни на нови таблици или полета.

В случая, за който разказвам, нещата бяха концентрирани около SQL Server и затова решението беше на чист SQL. Пускаш скрипта и си готов. Ако решим да го правим за Access или пък за нещо по-универсално, според мене е добре да използваме подобно описание, но с XML например. Може да се опише както първоначалното състояние, за да се генерира чиста база от начало, както и всяка една промяна със съответни тагове, например: <add table>, <add field>, <remove index> и т.н. И вътре пък да са описаният за тип, размер и пр.

Програмата, която ще следи за актуалността на базата ще има две функции: да чете текущата версия на базата и да я сравнява с тази в описанието и ако има разлика да изпълни инструкциите по ъпгрейда. Така всеки един ъпгрейд ще се дописва в XML файла и като се инсталира новия файл, тя сама ще извърши ъпгрейда. Ключовият момент тук е, че програмистът отговаря за самото описание и определя стъпките. В другия случай, ако имаш само 2 описания и програмата трябва сама да прецени кои са разликите и как да уеднакви едната база спрямо другата, ще бъде много по-трудно.

Малко дълги разсъждения, но се надявам да са били полезни.

Абе, не бе, човек. ;о) Въпроса беше за създаване и обновление на бази данни под VB6. Но таз програмка изважда и данните от базата в XML. Чудесно е, но щом работим с DAO, това е един просто алтернативен начин да прехвърлим данните в XML. Можем да отворим отделни теми за обсъждане на DAO, ADODB, XML, DBF дори... ;о)

Ето какво ни предстои да обсъдим: Начало на проекта. Програмиста си казва: "Ще има две таблици, първата ще има 4 полета, втората - 7 полета.". Ок, пише имената на таблиците и полетата в стринга, който е например в стартовия модул, и след него пуска процедурата за начално създаване на базата. Стартира приложението, и хоп - има си база. Пише каквото пише по програмата, пуска дистрибуция, клиентите си теглят програмата, ползват я, и вече имат данни вътре. Супер. Но след време му трябва още една таблица за новата версия на програмата. В стринга дописва новата таблица, ама тцъ. Нито е въпрос на създаване на нова база, нито няма как новата версия на програмата да продължи работа със стара база. Тогава какво правим. Трябва ни още една процедура, която след проверката за наличие на база - ако има съществуваща база данни - да я провери дали всички таблици и полета са по спецификация на версията на продукта. Ако липсва някоя таблица или поле - само да го добави, без да променя нищо по старите данни. Да кажем че не е трудно, но съм отворил темата, за да обсъдим какво може да потрябва, за да не го пропусмнем, да създадем "стандарт" за модула, и модула да го направим универсален, и да може да се добавя към всеки проект без промяна в кода.

И още една тема, засягаща бази данни, DAO, ADO, SQL, XML и т.н. простотии: Сортиране на записите в база данни! ;о)) ... Например имаме записи в базата, като 4 различни счетоводителки са въвеждали фактури в базата, но едната е отишла по-рано за кафе, и номерата на фактурите почват да се разминават:
1
2
3
8
5
9
4
6
10
7
...

На мен ми се иска като пусна ActiveReport - той само да отвори талицата, да вземе всички записи, и да ми отпечата справка за издадените фактури. Но тцъ, поредността на фактурите е нарушена. Трябва ни сортиране по номер, без да ползваме индексиране. ;о)

Щирлиц

И аз съм силно за XML, само че в този пример, човекът вади данните в XML, а на ас ни трябва преди всичко описанието на структурата, макар че може и за данни да се използва същата идея.

Е да де, говорим за едно и също нещо, само дето предлагам стандарта за файла с описание на таблици, полета и т.н. да е ХМЛ тип.(по дяволите... веднъж мина ли в Мозилата на кирилица не се връща на латиница.При вас има ли такъв проблем?) Може с модулчето да се разпространява някакъв примерен ХМЛ файл с обяснения за начинаещите, да си го редактират според нуждите си и готово. Между другото ако ще правим нещо за начинаещи е хубаво да обърнем внимание и на заявките. По мои наблюдения на това място май повече се затрудняват. Да направим нещо като визардче за съставяне на заявки(нещо подобно съм виждал в една складова програма - Зерон май беше). Пък ако се получи нещо свястно може да го метнем на едно ОСХ и да се използва от потребителите за съставяне на собствени заявки.