Google sheet jako baza danych ?

W bankach tak robią, tylko że excele a nie google shieeet :|

Wady są takie, że zrobisz tylko jeden arkusz, bo latanie po kilku mija się z celem. Bazy danych dodatkowo mają optymalizatory, indeksy, partycjonowanie oraz inne mechanizmy które przyspieszają działanie. Tak więc ogólnie zależy. Jak jedna tabela to jeszcze można pomyśleć, ale zależy od przyrostu danych. Jak więcej to imo nie ma sensu. Nie wiem też jak z samą wydajnością, ale podejrzewam, że przerobienie 1k wierszy sheeta jest wolniejsze, niż pobranie z jakiegoś sqllite. Ogólnie lepiej nie, bo prędzej czy później się to zemści, ale jak ktoś się uprze to może tak zrobić.

Soul_hunter_16 napisał(a):

Wady są takie, że zrobisz tylko jeden arkusz, bo latanie po kilku mija się z celem. Bazy danych dodatkowo mają optymalizatory, indeksy, partycjonowanie oraz inne mechanizmy które przyspieszają działanie. Tak więc ogólnie zależy. Jak jedna tabela to jeszcze można pomyśleć, ale zależy od przyrostu danych. Jak więcej to imo nie ma sensu. Nie wiem też jak z samą wydajnością, ale podejrzewam, że przerobienie 1k wierszy sheeta jest wolniejsze, niż pobranie z jakiegoś sqllite. Ogólnie lepiej nie, bo prędzej czy później się to zemści, ale jak ktoś się uprze to może tak zrobić.

dlaczego latanie po kilku arkusza mija się z celem ? Nie bardzo rozumiem. Wiele operacji może być tak naprawdę robione z poziomu guugla (inne arkusze pobierają dane z pierwszego) to raz - już oszczedzamy niejako na transferach (chyba)
może ktoś testował wydajność bo gdybać to można ?
i dlaczego ma się zemścić ?

Nieszablonowe pytanie :) Bazę danych możesz nawet trzymać w pliku txt. Excel narzuca po prostu pewien model danych i ma swoje ograniczenia wydajnościowe, z czasem danych będzie przybywać. Pytania, jakie bym zadał to:

1. Jakiego typu zapytania/kwerendy ma obsługiwać baza
2. Jak szybko ma odpowiadać baza
3. Jak nie stracić danych w przypadku awarii dysku
4. Jaka polityka retencji danych
5. Co z wspolbiezną modyfikacja danych, czy baza musi obsługiwać transakcje, jaka ma być ich semantyka (ACID, BASE?)

Wszystko się rozbija o wydajność + składanie tych danych w jakieś raporty, czy też dane wynikowe. Jednak śmiem twierdzić, że SQL lepiej ogarnia takie rzeczy niż pisanie skryptów, makr i programów do 20 arkuszowej bazy danych. Gdybać też sobie można jak nie podałeś jakie dane tam miałyby być trzymane, jaki przyrost danych, ile tabel. Tak więc można sobie gdybać dalej bez konkretów. Tak więc to wszystko zależy do czego to.

Charles_Ray napisał(a):

Nieszablonowe pytanie :) Bazę danych możesz nawet trzymać w pliku txt. Excel narzuca po prostu pewien model danych i ma swoje ograniczenia wydajnościowe, z czasem danych będzie przybywać. Pytania, jakie bym zadał to:

1. Jakiego typu zapytania/kwerendy ma obsługiwać baza
2. Jak szybko ma odpowiadać baza
3. Jak nie stracić danych w przypadku awarii dysku
4. Jaka polityka retencji danych
5. Co z wspolbiezną modyfikacja danych, czy baza musi obsługiwać transakcje, jaka ma być ich semantyka (ACID, BASE?)

Dobre pytania ale trochę skomplikowane jak dla mnie bo nie dotarłem do tego poziomu wiedzy po co mi polityka retencji danych czy też współbieżna modyfikacja danych , semantyka transkacje. W sumie nawet nie wiem co to jest ;- )

Zapytałem po prostu bo się ucze natomiast lekki projekt chce zrobic na których przeprowadzam proste kalkukacje matematyczne, w międzyczasie lub później chce pobierać dane z internetu (automatycznie) i móc je później w zależności od wyniku zestawiać czy też zwracać odpowiednio na stronie. Stąd też nie wiem czy musze od razu być ekspertem w sql itp itd.

A prócz tego teraz jest mnóstwo opcji wiec nie wiem już sam czy sens uczyć się sql, postgresa, dynamobb czy może wytarczy mi excel i może nawet efektywniej mi to pójdzie przynajmniej na początku ?

generalnie dzięki za ten post bo uświadami mi jak bardzo nie wiem co to jest baza danych ; -

Soul_hunter_16 napisał(a):

Wszystko się rozbija o wydajność + składanie tych danych w jakieś raporty, czy też dane wynikowe. Jednak śmiem twierdzić, że SQL lepiej ogarnia takie rzeczy niż pisanie skryptów, makr i programów do 20 arkuszowej bazy danych. Gdybać też sobie można jak nie podałeś jakie dane tam miałyby być trzymane, jaki przyrost danych, ile tabel. Tak więc można sobie gdybać dalej bez konkretów. Tak więc to wszystko zależy do czego to.

możez podać przykład co takiego może zrobić sql lepiej ??
przyrost danych ? nie wiem około 50 - 100 dzień ?

Ok, to w skrócie: naucz się SQL-a ;) na pewno Ci się przyda

SQL łatwiej wyciągniesz dane które Cię będą interesować łącząc np. kilka tabel. Jednak to zależy czy w ogóle będzie kilka tabel, czy tylko jedna. Czy będziesz chciał wyciągać dane, czy tylko je składować. Najlepiej to zrób to sobie. Jak mały projekt to może Ci wystarczy, jak nie to zobaczysz gdzie się zaczynają schody i będziesz wiedział, czy baza je rozwiąże.

Robiłem projekcik, w którym bazą jest Google Sheets. Polega to na tym, że jest tylko jeden arkusz ("tabela"), użytkownicy mogą odczytywać swoje rekordy (aplikacja w Apps Script), a "admin" wpisuje różne rzeczy w arkuszu. Ale aplikacja jest prosta - ma tylko odczytać dany wiersz z arkusza, a użytkowników jest niewiele (myślę, że nie więcej niż 200).

czy tylko ja mam takie wrażenie że tu w Polszy jakoś niby pomagamy ale tak tylko trochę - nie za bardzo. coś tam napiszemy ale tylko troszke , tak zebym przypadkiem za bardzo komus nie pomógł/nie pomogła

kociara napisał(a):

czy tylko ja mam takie wrażenie że tu w Polszy jakoś niby pomagamy ale tak tylko trochę - nie za bardzo. coś tam napiszemy ale tylko troszke , tak zebym przypadkiem za bardzo komus nie pomógł/nie pomogła

A jaka według Ciebie powinna być odpowiedź na tak zadane pytanie @opa?
Bo według mnie odpowiedź Ma to trochę sensu, ale nie za dużo i lepiej użyć bazy danych jest maksymalnie szczegółowa do tak ogólnego pytania