wiem, że moje pytanie jest bardziej teoretyczne niż techniczne, ale nie potrafiłam wygooglować żadnej wskazówki. Otóż mam komputer lokalny (jakby coś posiada zew. IP) na którym postawiona jest baza danych oparta o firebird’a (nie ma możliwości zmiany na MS SQL czy inne). Baza ta zawiera różnego rodzaju dane, głównie sprzedażowe. Chciałabym mieć możliwość wyświetlenia tychże danych w zewnętrznej aplikacji (czy to mobilnej czy webowej). W teorii więc przekazanie danych powinno chyba wyglądać tak:
FIREBIRD --> Serwer aplikacji --> Aplikacja
Prawda? W związku z tym mam kilka pytań:
Czy istnieją jakiekolwiek darmowe rozwiązania z GUI (lub w ostateczności konsolowe), które pozwalałyby mi na wypchnięcie konkretnych danych (tabel/rekordów) do serwera aplikacji?
Czy do aplikacji web/mobilnych mysql jest dobrym rozwiązaniem czy to zły wybór? Myślałam (ale to rozwiązanie pewnie na okrętkę…) by firebird wypluwał dane w formie gotowej do importu do serwera i tutaj skrypt php o ustalonych porach ładowałby te dane (ale minusem tego rozwiązania jest to, że taki plik importowy z biegiem czasu byłby coraz bardziej opasły)
Czy rozwiązania typu firebase / baqend można traktować wprost jako serwer aplikacji? jeśli tak, to jak to połączyć z bądź co bądź lokalnym firebirdem?
To wstępnie tyle dziękuję za wyrozumiałość i pomoc!
Raczej nie, takie rozwiązania wymagają spersonalizowanego rozwiązania. Poza tym serwer aplikacji powinien korzystać z serwera baz danych czyli np firebird, a nie że ty dodatkowo wypychasz dane z jednego serwera baz danych na drugi z którego korzysta aplikacja (chociaż to też zależy od aplikacji).
Równie dobrze może zostać firebird, to jakiej bazy używasz zależy od danych jakie przechowujesz. Można nawet w skomplikowanych i dużych projektach stosuje się nawet kilka różnych systemów baz danych w celu optymalizacji całej aplikacji.
Dziwna architektura. Może napisz coś w większym ujęciu i bardziej szczegółowo dlaczego chcesz to robić w ten sposób, zamiast postawić PHP oraz bazę na jednym serwerze i odwoływać się z aplikacji do bazy, czyli zastosować standardowe podejście.
Dlaczego dziwna? Możesz mieć, np. klaster serwerów SQL i jeden serwer aplikacji. Możesz też oddzielić, np. bazy danych od frontendu. Wszystko zależy od zastosowań i potrzeb. W rozbudowanych srodowiskach, tzw. standardowe rozwiązanie nie zawsze się sprawdza.
PHP nie może wykonywać zapytań SQL, że chcesz importować dane z bazy danych? Nawet jeśli napisałabyś własny skrypt php do eksportu danych, a na serwerze aplikacji do ich wyświetlanie, to wg mnie to nie ma sensu. Wydaje mi się, że na serwerze aplikacji lepiej wysyłać zapytania do bazy. Niestety nie znam się na pisaniu skryptów w php, więc tylko podpowiadam.
Słowem wyjaśnienia - pomyślałam o takiej architekturze z tego prostego względu, że:
firebird z bazą siedzi na serwerze, który pracuje od 8 do 21 (jest to normalny komputer na recepcji; z bazy korzysta program dla gabinetów wet.; nie ma potrzeby by pracował 24h/7)
pomyślałam o takim mostku który co pewien czas będzie ładować dane z firebirda do serwera aplikacji (z tego względu, że serwer aplikacji siedziałby sobie gdzieś na hostingu czyli mam do niego dostęp cały czas, a że czas pracy serwera w gabinecie kończy się o 21 to chcę mieć dostęp do danych danych)
Całość to tak naprawdę zadanie testowe dla mnie - żebym mogła się podszkolić w programowaniu i bazach danych.
W takim wypadku nie lepiej mieć wszystko gdzieś na hostingu zewnętrznym? I ewentualnie kopie w biurze? Zwiększasz bezpieczeństwo danych poprzez kopie, a dodatkowo masz 100% spójność danych bo dane są w jednym formacie i ich nie konwertujesz i przerzucasz z miejsca na miejsce.
Osobiście z takiego rozwiązania bym rezygnował jeśli nie ma ku temu naprawdę ważnych powodów (względy bezpieczeństwa, tylko część danych może być poza firmą, poufność danych itp. itd.). Takiego typu importy i konwersje z jednego typu bazy do drugiego czy z jednego silnika bazy do drugiego to zawsze ryzyko wystąpienia problemów podczas takiej operacji ze zgodnością pomiędzy takimi rozwiązaniami. Istnieje ryzyko że w wyniku aktualizacji po jednej stronie skrypt przestanie działać poprawnie i narobi szkód.
Owszem to co wyżej napisałem to mało prawdopodobne, ale ja bym nie chciał by akurat mi się przytrafiło.
Myślę że zbyt skomplikowany projekt sobie wymyśliłaś.
Generalnie całość jest do zrobienia, ale nie widzę ku temu powodów by realizować to w taki sposób. Poza tym to tylko wprowadzi bałagan, moim zdaniem jest to przerost formy nad treścią wręcz jak to się ładnie ostatnio nazywa over minding.