Duża baza danych?

Witam

Podpowiedzcie mi bazę danych.

Mam za zadanie stworzyć aplikację bazodanową. Okna będę robił w builder c++ na widowsa, natomiast która baza?
Użytkowników podpiętych będzie pewnie 1-3 ale za to baza będzie duża, czyli dochodzić będzie ok 1TB rocznie.
Generalnie sprawa wygląda tak, że będą tworzone zlecenia, które mają po kilkanaście pól ale do każdego zlecenia będzie podpinanych wiele plików, pdf, jpg itp.
Najbardziej lubię firebirda ale do małych aplikacji a co wybrać do tak dużej bazy? postgresa?
Jak z wydajnością serwera?

Pozdrawiam

Czekaj, co? Chcesz zapisywać pliki do bazy danych? :|

Hmmm ... a nie da się?
Firebird to robi więc założyłem, że poważniejsze bazy też.

Tak, da się - tak samo jak możesz nauczyć się chodzić na rękach zamiast na nogach, pytanie tylko: po co?
Ręce nie zostały stworzone po to, aby na nich chodzić, a bazy nie zostały stworzone w celu trzymania w nich plików.

Podzielam obawy @Patryk27 proponuję Postgresql lub Oracle jednak lepiej będzie jak w bazie zapiszesz w bazie nazwę pliku + ścieżka i udostępnisz to gdzieś w sieci lokalnej bo jest to znacznie wydajniejsze przy zapytaniach. Wyobraź sobie, że masz 100 rekordów w tabeli, a w każdej z nich pole z plikiem zapisanym binarnie. Jeśli każdy z plików ma 1MB to przy zapytaniu o 100 rekordów będziesz musiał tak na prawdę pobrać 100 rekordów + 100*1MB danych z pliku ... BEZSENS.

Niektórym silnikom baz danych wychodzi to całkiem nieźle. SQLServer ma kontener do przechowywania plików i działa to sprawnie. Mamy kilkanaście baz w których binarki tak siedzą i nie ma problemu.

No dobrze, ale użytkownik chce zlecenia i zdjęcia do nich w jednym miejscu.
Hmmmm ... czyli lepiej jest trzymać pliki na dysku a w bazie trzymać tylko linki do nich?
To rozwiązanie okrężne. Idealnie byłoby mieć wszystko w jednym, uporządkowanym miejscu czyli w bazie, ale wówczas to będzie strasznie rosło.

Jeżeli miałbym trzymać tylko linki, to w takim przypadku nie ma sensu wchodzić w postgresa tylko zrobić bazę w firebird.

http://stackoverflow.com/questions/3748/storing-images-in-db-yea-or-nay
do poczytania dla autora watku

tuz napisał(a)

To rozwiązanie okrężne.

Wręcz przeciwnie - to jest rozwiązanie idealne, ponieważ:
1.Nie musisz obsługiwać 1TB+ bazy. Wyobrażasz sobie robienie kopii zapasowej tego?
2.Możesz mieć kilka serwerów z plikami na całym świecie (CDN) i na nich trzymać te obrazki oraz dokumenty.
3.Plus te wszystkie argumenty, które są w linku od @fasadin

Było maglowane (tak, wiem zachowuję się jak bym z elektrody był)
Przechowywanie dużych plików w bazie danych

Sprawa w duży uproszczeniu wygląda tak, że jeżeli przechowujesz pliki w bazie to cała logika związana z ich obsługą jest opięta w transakcje bazy danych. Zatem nie nastąpi sytuacja gdzie masz "osierocone" pliki, bo na bazie commit się udał, ale nie udało się usunąć pliku albo gdy masz "null pointery", bo ktoś ręcznie usunął pliki z dysku, ale nie z bazy.

W takim wypadku jak twój można pomyśleć o rozwiązaniu polyglot data, czyli osobne źródła danych do przechowywania plików.

Patryk27 napisał(a):

tuz napisał(a)

To rozwiązanie okrężne.

Wręcz przeciwnie - to jest rozwiązanie idealne, ponieważ:
1.Nie musisz obsługiwać 1TB+ bazy. Wyobrażasz sobie robienie kopii zapasowej tego?
2.Możesz mieć kilka serwerów z plikami na całym świecie (CDN) i na nich trzymać te obrazki oraz dokumenty.
3.Plus te wszystkie argumenty, które są w linku od @fasadin

1. Backup... jeśli zrobisz go bez obrazków, to skończysz z niespójnymi danymi, więc grafikę też trzeba backupować, nawet jeśli to luźne pliki.
2. CDN dla trzech użytkowników aplikacji desktopowej?!
   3 a) Koszt przestrzeni bazodanowej we własnej sieci nie różni się od przestrzeni plikowej.
   3 b) Super optymalizacje dla 3 użytkowników?
   3 c) Łatwiej dla web servera. Jakiego web servera?

Do tego samemu trzeba obsługiwać transakcje na bazie danych i systemie plików, jeśli sceduje się to zadanie na samą bazę, to implementacja jest łatwiejsza.

Generalnie nie ma "idealnego rozwiązania dla każdego problemu". Wszystko zależy od tego, jaka to aplikacja, kto jej będzie używał, czy ważniejsza jest integralność, czy wydajność, itd.

Popatrz sobie na HDFS do trzymania plików. Jeżeli danych plikach jest bardzo dużo i przybywa, to pakując j te do tradycyjnego Rdbmsa bardzo szybko natrafisz na limit pojemności jednego serwera i albo będziesz musiał kupować bardzo drogi serwer, albo zmienić bazę na coś co się skaluje.

A transakcje na plikach? Nie widzę sensu. Transakcje powinny obejmować jak najmniej się da i działać jak najkrócej. Już to widzę jak ktoś streamuje 5 GB filmu przez jdbc w transakcji. :D

tuz napisał(a):

Witam

Podpowiedzcie mi bazę danych.

Mam za zadanie stworzyć aplikację bazodanową. Okna będę robił w builder c++ na widowsa, natomiast która baza?
Użytkowników podpiętych będzie pewnie 1-3 ale za to baza będzie duża, czyli dochodzić będzie ok 1TB rocznie.
Generalnie sprawa wygląda tak, że będą tworzone zlecenia, które mają po kilkanaście pól ale do każdego zlecenia będzie podpinanych wiele plików, pdf, jpg itp.
Najbardziej lubię firebirda ale do małych aplikacji a co wybrać do tak dużej bazy? postgresa?
Jak z wydajnością serwera?
Pozdrawiam

Baza danych? MS SQL Server 2014 w wersji Express (za darmo) z poprawnie skonfigurowanym i oprogramowanym FileStream.
W skrócie chodzi o to, że wkładasz pliki normalnie do bazy danych, ale silnik bazodanowy nie trzyma ich w bazie danych, a w specjalnym magazynie - są to zwykłe pliki na dysku.
W efekcie czego, baza nie puchnie (co bardzo ważne - rozmiar plików trzymanych w FileStream nie ma wpływu na ograniczenie wielkości samej bazy danych), dostęp do danych masz zapewniony przez SQL.
Odpada Ci ręczna synchronizacja plików z bazą danych - po prostu pobierasz je na klienta przez SQL.
Backup i restore bazy możesz zrobić z plikami trzymanymi w FileStram - lub bez.
Transakcyjność też jest zapewniona.

W necie jest pełno materiałów na ten temat, wystarczy poczytać i samemu przetestować.

Nie rozumiem, po co kopać się z koniem, jak wszystko jest podane jak na tacy...