5000 rekordów to każda z prezentowanych tu baz wistarczy...
Co do przetrzymywania zdjęć w bazie to ja jestem zwolennikiem trzymania linków do nich niż pakowanie ich do BLOBa. Operacje I/O to z reguły najbardziej obciążający proces, a z tym sobie najlepiej radzi OS.
Dla użytkownika nie ma znaczenia gdzie lądują pliki, ale to jaki ma do nich dostęp.
Z opisu wybierz bazę, którą znasz a liki trzymaj w poza bazą.
Ja bym wybrał Postgresa + ew. Elastica (choć chyba w Postgresie też można zrobić wyszukanie pełno tekstowe)
scibi_92 napisał(a):
Ja bym wybrał Postgresa + ew. Elastica (choć chyba w Postgresie też można zrobić wyszukanie pełno tekstowe)
Można, robiłem. Różnica jest taka że jak masz naprawdę dużo danych tekstowych do przeszukania pełnotekstowego to prościej postawić klaster Elastica niż klaster Postgresa. Z drugiej strony dla normalnych danych też trudno postawić klaster Postgresai i lepiej wtedy mieć np klaster Cassandry
Panczo napisał(a):
5000 rekordów to każda z prezentowanych tu baz wistarczy...
Co do przetrzymywania zdjęć w bazie to ja jestem zwolennikiem trzymania linków do nich niż pakowanie ich do BLOBa. Operacje I/O to z reguły najbardziej obciążający proces, a z tym sobie najlepiej radzi OS.
Dla użytkownika nie ma znaczenia gdzie lądują pliki, ale to jaki ma do nich dostęp.Z opisu wybierz bazę, którą znasz a liki trzymaj w poza bazą.
W MS SQL jest coś takiego jak filestream - bloby (varbinary(MAX)) przechowywane w filesystemie.
Jest transakcyjność, zawartość podlega backupowi jak dane z tabeli.
Z poziomu aplikacji w najprostszej wersji nawet nie musisz się tym zajmować, piszesz/czytasz jak do/z bloba, zawartość idzie wtedy przez bufory SQL-a, engine sam przekierowuje do filesystem.
Istnieje też bardziej skomplikowany ale wydajniejszy sposób, zawartość idzie wtedy z pominięciem buforów SQL-a.
Nie działa w Localdb.
Jeżeli dobrze rozumiem problem, to chcesz wyszukiwać w 5000 rekordów takie, które spełniają jakiś konkretny warunek. Np. chcesz mieć możliwość znalezienia wszystkich książek, których pierwsze wydanie miało miejsce w pierwszym dziesięcioleciu obecnego wieku, maja ponad 100 stron, przypisaną kategorię "fantastyka"?
Jeżeli tak, to użyj tego, co znasz najlepiej, albo jest najtańsze w utrzymaniu (MySql, PostgreSQL). Kompletnie nie ma znaczenia jakiej bazy użyjesz, możesz równie dobrze przy starcie usługi wczytywać do pamięci plik CSV i będzie działać.
Chyba że chcesz zaoferować jakieś dodatkowe kryteria wyszukiwania, np. wszystkie książki, które zawierają frazę "Harry Potter", albo wszystkie miasta wewnątrz jakiegoś obszaru itp. Ale jeżeli funkcjonalność tego serwisu mogłaby być zaimplementowana w Excelu z filtrowaniem po kolumnach, to naprawdę, nie ma co poświęcać czasu na rozkminę. Rozejrzyj się za jakimś hostingiem, zobacz co oferuje i użyj właśnie tego.
YetAnohterone napisał(a):
Skoro MySQL nie jest marny, to skąd się wziął mit o jego marności?
Skoro Postgres nie jest super-duper, to skąd się wziął mit o jego super-duperowatości?
chyba nie podales zadnych wymagan co do tego do czego mialaby zostac zastosowana dana, baza danych, a to wlasnie determinuje wybor.
Tak wiec generalnie, jesli ja mialem wybierac baze to w wiekszosci wypadkow wybor sprowadzal sie do: MySQL, PostgreSQL, Oracle (zakladajac, ze nie byly brane pod uwage NoSql). W zasadzie Oracle wybiera sie wowczas, gdy ma sie potrzeby, ktore spelnia glownie oracle oraz zasoby do tego. W pozostalych przypadkach oraz gdy ma sie do czynienia z mniejszymi systemami bazodanowymi wybiera sie pozostale dwie - to tak w skrocie, upraszczajac. Ja osobiscie uwielbiam oracle, ale nie do kazdego systemu jest sens stosowac ta baze.
pozdr
neves napisał(a):
Nie pracowałem za wiele z Oracle, także moje drzewko decyzyjne wygląda tak:
MSSQL - pierwszy wybór, jeśli tylko budżet pozwala,
PostgreSQL - jedynie wtedy gdy brak budżetu, albo potrzebujemy jakiś bardzo specyficznych indeksów których brak w MSSQL,
MySQL - nigdy więcej
SQLite - jak nie potrzebujemy współbieżnościMsSql to jest odpowiednik windowsa w świecie baz danych, pomyślany jak dla idiotów, wiele rzeczy zautomatyzowanych, profilowanie zapytania bajka.
Postgresql to jest odpowiednik Linuksa sprzed 20 lat, niby takie same możliwości jak windows, ale żeby osiągnąć podobne rezultaty jak na MsSql to trzeba się napocić i posiadać dogłębną wiedze o specyficznych rzeczach dla tego silnika.
Nie pisz takich rzeczy, poniewaz, osoby, ktore jeszcze nic nie umieja i zaczynaja z bazami moga przez pomylke pomyslec, ze MSSQL jest naprawde swietna baza - a to nie prawda (choc przyznam, ze jak na MS to ma troche plusow, chyba to jest ich najlepszy produkt w porownaniu do nieudacznych OS-ow) w porownaniu do innych baz. Moze podsumujmy to tak: "Nie pracowałem za wiele z Oracle"
przy okazji polecam: jak najdalej od microsoft - zawsze sie na tym dobrze wychodzi.
"odpowiednik windowsa" - czyli odpowiednik kupy smieci
"odpowiednik Linuksa sprzed 20 lat" - to jest klasa sama w sobie
pozdr
@pvw: Jak porównujesz MsSQL z Oracle, to nie wiem, czy Ms przegra tę rywalizację. Ostatni raz miałem z Oracle do czynienia lata temu, ale własne standardy zapytań, 3 biblioteki do obsługi XML i maksymalnie zrąbane narzędzia pamiętam do tej pory.