Wybór systemu do zarządzania relacyjnymi bazami danych (MYSQL, Postgres i MS SQL)

Jestem analitykiem, przygotowuje raporty dla kadra zarządzającej. Ostatnio padł pomysł o umieszczeniu danych w systemie do zarządzania relacyjnymi bazami danych.
Po przeczytaniu informacji z sieci i konsulatacjach z innymi analitykami dalej mam wątpliwość. Mój Dyrektor chce wykorzystywać MySQL tylko dla mnie ta pozycja bardziej nadaje się do wykorzystania na stronach internetowych niż do pracy analitycznej. Zastanawiam się nad trzema pozycjami.

• MySQL ,
• PostgreSQL,
• MS SQL Serwer 2008 R2 express,

Zawodowa styczność miałem tylko z Excelem (VBA, pivot table,vlooup itd) z SQL, T-SQL, ACCESS, MS SQL i postgresql tylko akademicką.

Generalnie dane będą przenoszone z excela lub access. Planuje około 400 000 lini rocznie lub więcej (plik excelowy będzie zajmował około 60 mega).
Dziękuje z góry za Wasze opinie.

Ta baza danych to jest jedna tabela? Ile ma pól i jakiego typu dane są w nich przechowywane?
Czy na podstawie danych mają być generowane jakieś raporty, tabele przestawne, itp.?

tylko i wylacznie MSSQL.
a) wersja 2012 a nie 2008 (od 2012 masz do dyspozycji columnstore index)
b) import mozna robic paczkami SSIS (w express dtexec)

Poczytaj o columnstore index (przed importem trzeba go usunac i zalozyc po imporcie).
Mozesz tez recznie importowac przez migration tools dolaczone do wersji MSSQL.

Dzięki za odpowiedzi.

Troche bardziej sprecyzuje informacje odnośnie danych. Na razie tak w skrócie mam dwa arkusze w excelu w każdym 20 kolumn z nagłówkami (po kilkaset wierszy z każdego dnia w sumie z całego roku będzie około 400 000 wierszy. Z tego genertuje automatyczne tabele przestawne, raporty dzienne, tygodniowe, miesieczne itd. Typ danych różne: liczby całkowite, dziesiętne, procenty i tekstowe.

Ja bym obstawiał PostgreSQL - darmowy i najbardziej dojrzały produkt jeśli chodzi o systemy baz danych z nurtu Open Source. MSSQL wymaga zainwestowania pieniędzy, a nie sądzę by miało coś, czego nie ma Postgres. MySQL odpada na mój gust.

Dzięki Hostel za odpowiedź.

Czy możesz jeszcze podać jakieś argumenty przeciw MySQL ??

Jednym jest na pewno słaba wydajności przy dużych bazach danych oraz ograniczony SQL (takie informacje znalazłem w internecie).

Jak się zdecyduje na któryś z tych systemów podeślę moje spostrzeżenia na forum.

MySQL nie wzbudza mojego zaufania. Kiedyś był problem z triggerami itp. Dużo bardziej profesjonalny jest Postgres - sądzę że warto wybrać tutaj od razu bardziej wydajne narzędzi niż później migrować gdy okaże się ze MySQL jest niewystarczające. Poza tym Pg posiada full text search(zaawansowane wyszukiwanie tekstu), fajnie pisze się triggery i funkcje. Mi także MySQL kojarzy się z zastosowaniami webowymi. Postgres ma mechanizmy do dodawania użytkowników do bazy danych, konfigurowania kto, z jakich IP i do jakiej bazy może mieć dostęp. Nie wiem jak to wygląda w przypadku MySQL ale bardzo możliwe że tam jest to mniej zaawansowane. Z własnego doświadczenia mogę dodać, że jest jeszcze Firebird SQL - lepszy niż MySQL ale jednak gorszy niż PostgreSQL. Tak więc możesz jeszcze na ten silnik popatrzeć. Plusem Firebird'a jest łatwość instalacji, można nawet uruchomić bazę bez instalowania całego serwera baz danych(wersja embedded). Minus Firebirda to mizerne mechanizmy dodawania użytkowników(chyba że coś się zmieniło przez ostatnie 2 lata).

Osobiście w firmie używam PostgreSQL, jeśli chcesz uniknąć ewentualnych problemów z konfiguracją to jest Firebird, MySQL bym unikał. Inna sprawą jest to w czym chcesz robić te raporty. Aplikacja webowa? Jeśli tak to w jakiej technologii? Aplikacja desktop? Jeśli tak to znowu pytanie o technologię. Drugim kryterium wyboru powinna być właśnie technologia, bo może się okazać że są trudności w pogodzeniu bazy z daną technologią.

Hostel napisał(a):

MSSQL wymaga zainwestowania pieniędzy,

Jakich niby pieniędzy wymaga MSSQL Server Express? O.o

a nie sądzę by miało coś, czego nie ma Postgres.

Reporting Services pozwalające na wyklikanie przeróżnych raportów dających możliwość eksportu do szeregu formatów oraz umieszczenie ich w intranecie z udostępnieniem opartym na użytkownikach domenowych?

@somekind akurat nie dałem Ci minusa. Nie minusuję osób, które mają swoje zdanie. Minusuję gdy ktoś popełnia błędy merytoryczne.

Przedstawiłem swój punkt widzenia, chcę by wątkotwórca wiedział o innych rozwiązaniach i możliwościach. Co do raportowania to istnieją narzędzia na licencji LGPL, które spełniają takie zadania. Pierwsze z brzegu to OpenRPT ale nie wypowiem się na ten temat, ponieważ nie pracowałem na tym. Mogę zdradzić tyle, że planuję wykorzystać to narzędzie we własnej aplikacji typu desktop.

Natomiast kiedyś korzystałem z BIRT Project(Eclipse). Powinno mieć obsługę PostgreSQL. Narzędzie to jest oparte o Java EE jeśli dobrze pamiętam i chodziło na Apache Tomcat. Fajnie pod Eclipse robiło się raporty - typowy drag & drop.

Widze ze chyba nikt nie pracuje na MSSQL.
Ograniczenie to 10GB. Ograniczenie pamieci wlaczajac CLR 1.4 GB.
Ograniczenie do 1 fizycznego procesora.

PS. Rozne zdania zdaniami ale bardziej dojrzalego prduktu niz MSSQL nie ma :)
PS2. chodzi o wersje express.

@crowa a Oracle Express? Nie wiem w czym wg ciebie MSSQL jest bardziej "dojrzały"

W pelni kompatybilny ze srodowiskiem serwera.
Np C# (CLR), konta anonimowe (MSA), wsparcie architektury on-fly.
I to co chyba najwazniejsze w tym temacie dla OLAP columnstore index.
Stabilnosc kolejnej wersji silnika :)
Brak mozliwosci okreslenia rozmiaru extenta :( Oracle ma z tego co kojarze.

Z mojego doświadczenia to Oracle jest "lepszy", a już na pewno pl/sql daje większe możliwości niż T-Sql, jednak M$ jest o wiele przyjemniejszy w pracy, lepsza dokumentacja, lepsze narzędzia, większa intuicyjność itp. itd..
Jak taka instytucja jak Oracle może się nie wstydzić takiego SQL Developera...

@jastrzab84 - weź jeszcze pod uwagę SQLite ;) Łatwo ją oprogramować w różnych językach, w C/C++, C#, PHP, Python i wiele więcej ;) Jest to baza oparta na pliku, więc nie trzeba nic konfigurować. Są aplikacje do zarządzania, np. Sqliteman - http://sqliteman.com/ - polecam ;) Licencja SQLite jest "bardziej darmowa" niż opensource - public domain.

mssql tez ma baze jednoplikowa :)

crowa napisał(a):

mssql tez ma baze jednoplikowa :)

I co z tego, skoro liczy się tutaj zasada działania?

autor potrzebuje silnika do celow olap.
A MSSQL 2012 ma columnstore index - cos co sprawdza sie idealnie przy tego rodzaju wymaganiach.
Nie ma sensu analizowac mozliwosci silnikow - jednynie mozliwosci w przypadku OLAP.

http://msdn.microsoft.com/en-us/library/gg492088.aspx

Nie wiem czy Oracle ma cos takiego. Osobiscie widzialem to w dzialaniu podczas SQL Day we Wroclawiu.
Robi wrazenie :D

ok, a jaka baze polecacie do napiasnia inzynierki ( w delphi) ?

baza relacyjna, ale tylko oblusga zwyklych tabel i kwerend wstaw, usun , edytuj itp ?

w chiwli obecnej mam mysql loklanie postawionego na Wampie,
a w przyszlosci nie bedzie to chyba dobre rozwiazanie

Spine napisał(a):

@jastrzab84 - weź jeszcze pod uwagę SQLite ;) Łatwo ją oprogramować w różnych językach, w C/C++, C#, PHP, Python i wiele więcej ;) Jest to baza oparta na pliku, więc nie trzeba nic konfigurować. Są aplikacje do zarządzania, np. Sqliteman - http://sqliteman.com/ - polecam ;) Licencja SQLite jest "bardziej darmowa" niż opensource - public domain.

Sqlite to ja bym nie nazwał w ogóle bazą danych. Można to wykorzystać do zapisywania danych takich jak np. ustawienia programu albo ogólnie jakieś dane - zamiast zapisywać do pliku tekstowego, można zapisać za pomocą sqlite i potem łatwo wczytać, oszczędzając sobie konieczności parsowania pliku.

Ale nie wiem jak sqlite ma spełnić wymagania, skoro twierdzicie że mysql ma za małe mozliwości - przecież tu nie ma nawet żadnej autoryzacji, praktycznie żadnej obsługi wielu połączeń z tą samą bazą (tak, bo to przecież otwieranie pliku i nic więcej - kilka osób nie może jednocześnie tego samego pliku edytować). Nie ma obsługi procedur ani funkcji, triggery o ile pamiętam też maksymalnie ograniczone itd. Sqlite moim zdaniem sie nie nadaje do tego celu.

http://pl.wikipedia.org/wiki/SQLite#Zastosowanie - ale nie, zdaniem @othello SQLite to nie jest baza danych...

Człowieku, to nie jest baza danych w dosłownym rozumieniu tego słowa, z powodu braku rzeczy o których napisałem powyżej. Nie daje sie zastosować w przypadku gdy potrzebujemy bazy danych z prawdziwego zdarzenia - nie do tego jest przeznaczona. Umożliwia niewiele więcej niż otwarcie pliku z danymi i pobieranie z niego danych/dopisywanie danych za pomocą prostej składni sql. Tylko tyle i aż tyle - nie jest to ani zamiennik mysql ani mssql ani oracla czy jakiejkolwiek innej bazy danych i nigdy nie miał nim być. Już brak możliwości jednoczesnego połączzenie kilku użytkowników i bezproblemowej pracy na tej samej bazie/tabeli od razu dyskwalifikuje sqlite jako typową bazę danych, nie mówiąc już o całej reszcie. Brak sensownej autoryzacji przy łączeniu z bazą tak samo.

Nawet te zastosowania, które są tam wymienione to potwierdzają - aplikacja trzyna po prostu swoje dane/ustawienia w pliku. I do tego się sqlite nadaje wyśmienicie, po co wynajdowac koło od nowa i tworzyć swój własny format pliku do przechowywania danych, skoro mamy do tego wygodne w użyciu sqlite. Po prostu używajmy narzędzi zgodnie z ich przeznaczeniem - tam gdzie sqlite jest najlepszym wyborem, tam jest używane.

othello napisał(a):

Nawet te zastosowania, które są tam wymienione to potwierdzają - aplikacja trzyna po prostu swoje dane/ustawienia w pliku. I do tego się sqlite nadaje wyśmienicie, po co wynajdowac koło od nowa i tworzyć swój własny format pliku do przechowywania danych, skoro mamy do tego wygodne w użyciu sqlite. Po prostu używajmy narzędzi zgodnie z ich przeznaczeniem - tam gdzie sqlite jest najlepszym wyborem, tam jest używane.

W zastosowaniach jest np. Trac. I raczej SQLite nie jest tam używany tylko do przechowywania konfiguracji.

othello napisał(a):

[...]nie jest to ani zamiennik mysql ani mssql ani oracla czy jakiejkolwiek innej bazy danych i nigdy nie miał nim być[...]
Nie daje sie zastosować w przypadku gdy potrzebujemy bazy danych z prawdziwego zdarzenia - nie do tego jest przeznaczona

Cytat z http://docs.python.org/library/sqlite3.html :

It’s also possible to prototype an application using SQLite and then port the code to a larger database such as PostgreSQL or Oracle.

Czyli nadaje się do wstępnej pracy nad większymi systemami.

othello napisał(a):

Już brak możliwości jednoczesnego połączzenie kilku użytkowników i bezproblemowej pracy na tej samej bazie/tabeli od razu dyskwalifikuje sqlite jako typową bazę danych, nie mówiąc już o całej reszcie.

cytat z http://www.sqlite.org/faq.html#q5

If your application has a need for a lot of concurrency, then you should consider using a client/server database. But experience suggests that most applications need much less concurrency than their designers imagine.

W jakimś filmie słyszałem, że to co jest przed ale (but) się nie liczy :D

Czy ty jestes upośledzony? Ciągle mowa o stosunku 1:1 - czyli aplikacja łączy się ze swoją bazą danych, wtedy rzeczywiście z reguły nie potrzeba współbieżności. Problem się zaczyna dopiero wtedy, gdy 2,5, 10 kopii tej aplikacji potrzebuje korzystać z tej samej bazy, a użytkownicy wszystkich kopii programu mają widzieć te same dane i wspólnie z nich korzystać. To drugie to 99% przypadków bo sama idea bazy danych jest właśnie taka.

Sqlite ma zastosowania takie jakie ma a ty w ogóle nie wiesz o czym piszesz, nie warto już więcej z tobą dyskutować. Kiedyś jak już dorośniesz i zaczniesz pracę zawodową, to np. z systemu w banku, na głównym serwerze bazy danych wywalisz oracla, zainstalujesz sqlite, przepiszesz cały kod łącznie z procedurami, funkcjami, triggerami na sqlite, sam dopiszesz mechanizmy autoryzacji, zdalnego połączenia z bazą przez sieć itd. Tylko mam nadzieję że nie przyjdzie mi pracować z takimi jak ty.

Skoro autor tematu miał do czynienia tylko z Excellem i potrzebuje bazy tylko do pracy analitycznej, a nie do stron internetowych, to nie trzeba mu dostępu dla wielu użytkowników...

Mój Dyrektor chce wykorzystywać MySQL tylko dla mnie ta pozycja bardziej nadaje się do wykorzystania na stronach internetowych niż do pracy analitycznej.[...]
Generalnie dane będą przenoszone z excela lub access. Planuje około 400 000 lini rocznie lub więcej (plik excelowy będzie zajmował około 60 mega).

Wnioskuję, że i tak lokalnie będą tego używać i wystarczy 1:1 - nie będzie wymagana współbieżność ;) Ty @othello może lubisz strzelać z armaty do mrówek, ja nie bardzo...

No ale wiesz, zdaje sie że sam autor powątpiewał w funkcjonalność mysql. Więc tym bardziej sqlite go nie zadowoli. I było to uzasadnione - dlaczego.

Spine napisał(a):

Wnioskuję, że i tak lokalnie będą tego używać i wystarczy 1:1 - nie będzie wymagana współbieżność ;) Ty @othello może lubisz strzelać z armaty do mrówek, ja nie bardzo...

Autor tematu napisał w pierwszym zdaniu:

Jestem analitykiem, przygotowuje raporty dla kadra zarządzającej.

Raporty. RAPORTY. RAPORTY.

A teraz przedstaw nam jakieś wygodne i wydajne narzędzie do tworzenia raportów w SQLite.

somekind napisał(a):

A teraz przedstaw nam jakieś wygodne i wydajne narzędzie do tworzenia raportów w SQLite.

http://www.kexi-project.org/
http://knoda.sourceforge.net/

somekind napisał(a):

Raporty. RAPORTY. RAPORTY.

Przypomina się hit Ballmera :D - http://video.google.com/videoplay?docid=6304687408656696643

Hostel napisał(a):

Osobiście w firmie używam PostgreSQL, jeśli chcesz uniknąć ewentualnych problemów z konfiguracją to jest Firebird, MySQL bym unikał. Inna sprawą jest to w czym chcesz robić te raporty. Aplikacja webowa? Jeśli tak to w jakiej technologii? Aplikacja desktop? Jeśli tak to znowu pytanie o technologię. Drugim kryterium wyboru powinna być właśnie technologia, bo może się okazać że są trudności w pogodzeniu bazy z daną technologią.

Będę wykorzystywał aplikacje desktop, odnośnie technologi to na razie nie wiem. Generalnie mam w planie przerzucać dane z poziomu excel lub access do np. postgreSQL i tam te dane przechowywać i ewentualnie je wykorzystywać do przygotowywania raportów.

tylko pytanie na czym Ci zalezy najbardziej.
Jesli to ma byc OLAP z szybkim dostepem do danych to tylko MSSQL 2012 i column store index.

kurczaczek, o co choddzi z tym 'column store index'? czy to jest ciepłe miękkie i wilgotne? w każdym poście to zachwalasz

dziesiąt tysięcy czy nawet set tysięcy dla porządnej bazy danych to jest pierdnięcie, bez żadnych wynalazków.