Моля, ако някой знае начин, по който да създам бази данни, които съдържат информация, въведена в програма писана на делфи и има време и желание да помогне да обясни как точно се прави това създаване и как се извършват са по-простичките операции (като вмъкване, изтриване, и създаване на нова таблица)
благодаря ви предварително...

Кажи поне каква искаш да е базата данни... Нещата много зависят от това

Съдържаниет е скрито
Влезте за да го видите

"нещата" зависят и от твоята квалификация - напиши нещо за себе си: ползваш ли понятия като "поле", "запис", "SQL", програмирал ли си и къде точно в програмата на делфи е въведената информация?
И май ми се струва, че в края на краищата ще ти се наложи да четеш книгите и/или документацията, ама поне ще сме те насочили :)

Ми обикновени имена на кирилица...
Възможно най-простите бази данни...

Може би не си уцелил правилният клуб...

Пробвай, моля, в
http://clubs.dir.bg/wwwthreads.php?Cat=174

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

Айде весели празници...

Иначе това ми е първия проект с бази данни ... преди съм се занимавал с програмиране на Борланд Паскал... Което си е чисто делфи както се обедих по-късно.. Програмата е завършена и остава да пазим едни списъци с данни в бази данни...

Ако програмата ви е завършена, значи данните са в масиви или някакви записи.
Тогава база данни не ти е нужна, можеш да ползваш стандартните файлове - точно като в Turbo Pascal.
Възниква обаче въпроса за чий чеп ти искат да съхраняваш данните в база? Няма да е лошо да дадеш повече инфо - какво гониш като цел, кой ти е спуснал идеята за базите и прочее - за да може да ти се отговори нормално.

чети и дишай по-леко

и както ти пишат андрю и печения:) бази данни през делфи можеш да ползваш всякакви: парадокс, дибейс, акцес, майскл (мъсял:)-MySQL и т.н.

И аз да се включа в темата с един въпрос:
Искам да направя нещо като електронен каталог - 5-6 таблици които съдържат артикулите които се ползват с цени и характеристики, някакви групи, марки...в този случай не ми трябва кой знае колко стабилна база - едва ли има смисъл да си платя Oracle примерно :). Ще отбележа, че няма да имам потребителски права, пароли, History на операциите и т.н. - просто справка, и основния критерий е бързодействието при голям набор от данни (примерно 100000 записа, всеки съдържащ данни от порядъка 30 Bytes). Питанката ми е MS Access, MySQL - май новата версия била доста добра, Interbase и т.н. - как да избера база? И ако някой може да ми каже - в Delphi 5 и 6, връзката с MySQL с ADO компонентите ли става?
Мерси на запознатите

За такава мизерна база е чудесно да се ползва Firebird. Има приличен шел (IBExper например), чудесна интеграция с Delphi и ред други предимства, които не могат да изкупят с някакви жалки милисекунди...

чети и дишай по-леко

Ако за достъп до базата ползвам IB Components, това ще ми даде ли бързодействие? И ако има по-добър начин за работа с Delphi и FireBird - какъв е той?
Мерси на запознатите :))

По мое скромно мнение Paradox e най добрата БД за desktop приложения,
много по бърза от ACCESS и по лесна за използване през Делфи/ВСВ. Ако има недостатък, това е че трябва да инсталираш BDE на всяко PC. Paradox се справя добре и при многопотребителска работа (20-30 user-a мах), но трябва да се спазват някои прости правила - отваряш, пишеш, затваряш БД по най бързия начин - ако работиш с TTable, никакви гридове или др. потребителски глезотии.
За MySQL : Аз лично работя през АДО. Изтегли и инсталирай от сайта www.mysql.com ODBC драйвера. Другият вариант, е да използваш ZEOS компонентите - безплатни - от сайта www.zeoslib.net. В този случай, няма нужда да инсталираш допълнителни драйвери на клиентските PC-та.
Пробвах без особен успех да се вържа с dbExpress компонентите от C++ Builder 6 към MySQL.

Понеже се натрупаха въпроси, на които може да се отговори бързо, но не и ясно, е добре да се дадат някои обяснения.
Избора на една база данни зависи от няколко критерия. В повечето случаи те са взаимоизключващи се, затова е добре да се прецени всеки критерий и неговата тежест, за да може да се избере най-добрия вариант.
Критериите (това не са всички, разбира се, само най-важните) са:
- мобилност на приложението. Това означава инсталирането и съответно пренасянето на приложението и неговата база данни да става най-лесно и удобно. Тук безспорен шампион е MS Access - от 2000 нагоре плюс всички по-стари инсталации с офис например са готови за работа. Базата данни в общия случай е един файл, който може да се тръшне в същата директория. Това плюс кадърно написано приложение позволява инсталирането и преноса да става с Copy/Paste
- бързодействие Тук е безсмислено да се спори коя база е по-бърза. Достатъчно е да е достатъчно бърза Огромна част от бързодействието зависи от проектирането на самата база - таблиците, индексите, начина на извличане на данните и прочее. Перфектния вариант е да се направи примерна база, да се изпълни примерна заявка и да се види дали резултата ни влиза в работа. Хубаво е да има възможност за еволюция на базата данни - т.е. тя да може да се пренесе на по-мощна система ако се наложи. Най-тъпото в случая е да се слушат съвети на сляпо - колкото хора се питат, толкова мнения ще се чуят.
Във всеки случай едно е сигурно - еднаква като функционалност база данни може да се проектира от различни хора с драстични разлики в бързодействието. Така че за техническите подробности е добре да се пита.
- сигурност, стабилност и архивиране на данните. Всеки голям сикуел сървър (например Оракъл и Микромекия Сикуел) има достатъчно възможности за сигурна, стабилна многопотребителска работа. Отлична възможност е обаче Firebird - с малко повече майсторлък може да се постигнат впечатляващи резултати. Усвояването на работата с транзакции пък гарантира една почти 100% безпроблемна работа.
- удобство при работа. Тук е важно да можем да проектираме бързо и лесно една база данни, както и да имаме удобен графичен интерфейс с контрол над възможно най-голям брой опции. Чудесни среди за изграждане на бази данни са Access и особенно MS SQL Server, PL/SQL Developer за Oracle, IBExpert за Interbase/Firebird
- интеграция с Delphi тук са важни две неща - да се девелопи с click&play, компонентите да са native, демек да са проектирани специално за тази база - ADO за M$, Direct Oracle Access за Oracle, IB за Interbase/Firebird и т.н.
Ако трябва да се даде някакво обобщение, най-много точки набира Firebird - безплатен, с безплатна и юначна конзола, трениращ полезни умения за работа с бази данни - тригери, транзакции и прочее, с прилична производителност и инструменти за менажиране. Особенно за начинаещи и среднонапреднали програмисти, това е прекрасна алтернатива.
Накрая искам пожелая на хората, дали си труд да ме четат - ЧНГ!

чети и дишай по-леко

Само ще добавя, че Firebird има версии както client/server, така и embedded, т.е. десктопна СУБД. Преминаването от едното към другото е... а бе много е лесно.

Добре де, embeded какво ще рече?
Ако моето приложение ползва дадена база(файл), на клинетското PC трябва ли да се инталира нещо?

Щото съм ползвал някой други разновидности TiniDB и забравих как се казваше вече... :) , та при тях е така. Позлваш си само един файл на клиентското ПС и това е...

А и доста работи съм изчел за FB, ама никъде не намерих как да ползвам embeded функционалността... Та ако можеш да дадеш малко подробности...

Да не си говорим, че ако си майстор и работиш в КешЪпдейт варинат и управляваш правилно транзакциите Interbase/Firebird не отстъпват на "големите" сървъри, поне докато базата не прехвърли 1 гигабайт. Тогава се наблюдава забавяне на работата, при по тежки заявки(ама кой пречи базата да се разцепи?!?!?). Въпреки, че моите разбирания за добро проектиране на една апликация за бази данни са:
1. Базата трябва да е проектирана, така че: ТЕЖКИ ЗАЯВАКИ ДА НЯМА.
2. Апликацията трябва да е проектирана така че: ПОТРЕБИТЕЛЯ ДА ПОЛУЧАВА ОБОЗРИМ БРОЙ РЕДОВЕ ОТ БАЗАТА, не 5000 например т.е при едно отваряне на екран да вижда не повече от няколкостотин реда. Всичко останало наричам ЛОШО ПРОЕКТИРАНЕ.
3. Големите обеми от данни минават във УърХаус, като оставят възможност за относително МАЛКА и бърза ОПЕРАТИВНА база данни, която е в "текущо ползване".
Иначе казано за средно статистичексо българско предприятие Interbase/Firebird - вършат перфектна работа, като в Interbase 7 има доста подобрения(но е платен). Много специалисти казват, че големия проблем на Interbase/Firebird са вютата. Аз отговарям:вютата са ЗАБРАНЕНИ за използване похвати за добрия ПРОЕКТАНТ ***.
СЪС ЗДРАВЕ

Редактирано от Pechenia на 06.01.05 18:11.

Общо взето поддържам изказаното по-горе мнение с няколко добавки. IB/FB е чудесна база за малки до средни проекти, която е супер лесна за инсталиране и поддръжка. Дет' се вика "пали от раз" . Но според мен не толкова обема на данните, колкото броя потребители е критичния за системата, що се отнася до IB/FB. Ако се навържат повече потребители (над 50-60 едновременни конекции), работата започва да става доста трудна, дори и при добре проектирана структура на базата и логиката. Основния проблем е, че IB/FB е ориентирана към десктоп сървъри от нисък клас и просто не може да ползва системните ресурси на голям сървър, независимо, че ги има. Едва в последната версия на IB7 се появяват някакви оптимизации за мултипроцесорна (SMP и/или HT) поддръжка. Но както казах, това не е проблем за едно средно предприятие или фирма у нас, където персонала рядко надхвърля 50 човека, а от тях цъкащите на компютри са не повече от 10% .

Mixy

Embeded версията представлява същият сървърски енджин набутан в клиентската библиотека (gds32.dll или fbclient.dll), така че се имитира клиентска инсталация, а вместо да се прави отдалечена връзка към сървъра това става директно на място.
Към Embeded можеш да се вържеш без парола, защото isc4.gdb/security.fdb така или иначе изобщо го няма, но се спазват правата на юзера, с който си се логнал в базата.
Използвайки Embeded можеш да се вържеш само локално, т.е. C:\SomeDir\SomeDB.fdb и не можеш да ползваш TCP/IP и т.н. дори и localhost или 127.0.0.1.


ПП Забравих още нещо важно. Към Embeded можеш да направиш само 1 кънекция. Ако приложението ти изисква повече, например имаш пулинг или пък просто ползваш повече връзки трябва да използваш сървърската версия.

Съдържаниет е скрито
Влезте за да го видите

Редактирано от andrew_nikoloff на 06.01.05 08:38.

Глупако думата е ИНЖЕНЕР. А ти си ***

Редактирано от Pechenia на 06.01.05 18:10.

С оглед на прагматичния стил във форума се наложи да редактирам мнението на The Engeneer, съответно за да има справедливост, редактирах и вашето.
Приемете моите извинения, аз ужасно ненавиждам подобна дейност.

чети и дишай по-леко

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

There are three determined states the cat could be in: Alive, Dead, and Bloody Furious.

Хехехехе - нещо си в голяма грешка ;-))))
Имам бивши клиенти - с по 3 до 5 компа - които не са ме търсили цяла година - обикновено ми се обаждат накрая за да re -pack-на базата преди да я архивират. Всичко опира до настройка + читава мрежа + читави компове + UPS !!!! Това с факторите за безупречната работа на Paradox-a.

---

прав си, донякъде помага и условието читави юзъри :)

Чудя се доколко SQLite може да работи мрежово, щото съм много доволен от работата й на единична машина...?

There are three determined states the cat could be in: Alive, Dead, and Bloody Furious.

Редактирано от Koтapakът нa Шpьoдинrep на 07.01.05 01:07.

andrew_nikoloff вече каза, само да добавя: слагаш базата данни, gds32.dll и твоята програма в една директория, и всичко работи. в connection string не се указва "myserver:D:\DB.FDB", a "само D:\DB.FDB". Виж например тук: http://www.volny.cz/iprenosil/interbase/connect_string.htm

Освен клиентския DLL трябва да се сложат и останалите неща, които са необходими на сървъра - aliases.conf, firebird.conf, firebird.msg, ib_util.dll и папките intl (ако базата ти има charset) и udf (ако ползваш udf-и).

Съдържаниет е скрито
Влезте за да го видите

---->
Основния проблем е, че IB/FB е ориентирана към десктоп сървъри от нисък клас и просто не може да ползва системните ресурси на голям сървър, независимо, че ги има. Едва в последната версия на IB7 се появяват
<--------
Започвайки от FB 1.5, отново има вариант "classic", при който за всяка конекция се поражда нов процес; при това се ползва повече памет отколкото при варианта "superserver", но пък дву-и повече процесорните конфигурации се използват напълно.
Това го знам само теоретично, но до месец при нас ще сложим двупроцесорен сървър, и ще проверя на практика :)

Верно. Отдавна не съм го правил, затова забравих.

Лошото на Classic версията е, че все още не е имплементирано цялото Services API. А на мен точно те ми трябваха

Съдържаниет е скрито
Влезте за да го видите

Друг проблем е именно тази "допълнителна" памет за всеки процес. Някъде бях мернал, че е около 30MB/конекция (може и да греша). Ако за сървър се ползва примерно PC с 1GB RAM, (256 MB за Win, останалите за IB/FB) то теоретично биха били възможни само 25 конекции, след което ще свърши паметта, а swap-файла тук почти не играе. Но това трябва да се проиграе, защото теорията е едно, а практиката - съвсем друго нещо.

Mixy

----
Лошото на Classic версията е, че все още не е имплементирано цялото Services API
-----
В FB 1.5.0 - не, но в 1.5.1 вече май да. От това на което съм обърнал внимание- backup/restore вече върви, статистиките - също.

И аз четох за тези 30 МБ. Обаче ползвам Classic в реална БД, и при мен са 5-6MB на процес. Не знам от какво зависи.

В отговор на:

---

и при мен са 5-6MB на процес. Не знам от какво зависи.

---

Съдържаниет е скрито
Влезте за да го видите

IBSec-а не работи. Не можеш да добавяш и редактираш юзери. В 1.5.2 все още е така. Останалото не съм го ползвал и не знам.

Съдържаниет е скрито
Влезте за да го видите

Сега, като се замисля, организацията на транзакциите също би трябвало да е от значение. IB/FB използва оптимистично заключване, което означава, че всяка започната транзакция кешира даден обем от информация в паметта и/или диска (това зависи и от ОС). Кокото по дълга е транзакцията и се натрупват други след нея, толкова повече памет отива за моментните snapshots на данните. А това пък зависи от структурата, приложението (програмата) и броя навързани потребители , а сигурно и от други неща ...

Mixy

Това зависи от много неща - от броя на потребителите, от размера на данните, от броя на транзакциите, от броя на базите, от размера на страницата... Абе сложна работа
SuperServer-а ползва общи буфери за страниците за всички юзери, докато Classic има отделен процес за всеки свързан потребител и съответно копие на буферите. По дебелите книги пише, че SuperServer като цяло ползва по-малко ресурси "за клиент", но за малък брой на свързаните потребители Classic общо ползва по-малко памет. Ама колко точно е "малък брой" не мога да кажа
Всичко казано до тук за сравнение между двете архитектури важи разбира се само при еднакви настройки и еднакви бази. Ако аз си увелича размера на буферите естествено, че сървъра ще ми гълта повече памет :)))
Като заключение мога да кажа, че нещата зависят от конкретната ситуация - броя бази, броя юзери, операционната система, самата база... И нищо на тоя свят не е чисто черно или чисто бяло

Съдържаниет е скрито
Влезте за да го видите

---
IBSec-а не работи. Не можеш да добавяш и редактираш юзери. В 1.5.2 все още е така.
---
Аха. Ще гледаме напред към следващите версии :)

Значи ли това, че ако една процедура от модула се извършва в една транзакция схте цукли много пожецхе, отколкото ако е разбита примерно в 5? (СТИГА ДА Е ВЪЗМОЖНО ДЕ :))

В отговор на:

---

...се извършва в една транзакция схте цукли много пожецхе...

---

В отговор на:

---

...една процедура от модула се извършва в една транзакция...

---

Съдържаниет е скрито
Влезте за да го видите

А какво става, ако има suspend в тялото на процедуратра?

Може би бъркам понятията, но suspend не прави ли нещо такова?

Не. Suspend връща ред в резултата

Съдържаниет е скрито
Влезте за да го видите

Това е от последния брой на DB & ERP изданието на IDG:

Съдържаниет е скрито
Влезте за да го видите

Това е съкратен превод на ей- това:

Съдържаниет е скрито
Влезте за да го видите

Да, ясно. И аз предположих, че е превод от някъде, но бая неугледно са го орязали ...



Mixy

А, додохме си на думата! Почти си прав!
Има само едно уточнение, което искам да направя, проблем възниква при много сесйи, ако всички работят в постоянен режим четене-запис и пак......
В противен случай ползваме компонненти на IBExpress, пускаме ги в състояние на CacheUpdate и "пей сърце" т.е потребителя прави всички операции на куп, когато си е свършил работата или Rollback, ако нещо не му харесва. При този подход една сесия натоварва базата за много кратко време. В заключение мога да кажа, че е подходящ и за големи фирми, зависи от обема данни който се обработва в една транзакция. Това с управлението транзакциите е "много тънък" момент. За какво не е подходящ: не е подходящ при ситеми, които паралелно с активни ъпдейти пускат и "тежки" справки върху базата. Това са някои обществени организации и системи, които работят с големи "блоб-полета", например съхранение на закони и техните поправки, но и от това има изход, като няма да се спирам на него сега.
Слабостта на IB-то в сравнение с големите сървъри е в "оптимизация на заявките" - например да направи joint на голяма таблица сама по себе си и в условието да включиш "count distinct Field_key1...." на такива неща се "осира".
За подобни заявки най-силни са Ораcle и DB2, боклука на Microsoft за нищо не става, ако изключим някои силни модули за хеширане, към него.......
С едно изречение: IB-то е само са професионалисти..............

BDE поддържа ли се в Д2005? Имам предвид не само за обратна
съвместимост, а дали продължава да се разработва? Удачно ли е
да го ползвам в Д7 за приложение, което работи с малка локална
база данни на Парадокс с няколко таблици?

най-лесно ще ти е(предполагам) с Paradox, от Database Desctop избираш New->Table-> Paradox7.0

Windmaster