Full-search to bardzo dobry pomysl i bardzo dobra funkcja ktora
mozemy oferowac. Powiedzialbym ze niemal krytyczna. Skoro jednak ma ona
duzy wplyw na wymagania co do systemu bazy danych a zatem ma wplyw na
koszty po naszej stronie to moze powinnismy oferowac to jako add-on.
Taki add-on powodowalby upgrade RDS do odpowiednio wiekszego oraz
utworzenie dodatkowego indeksu dla full-search.
Hm. niby tak ale kolumna w bazie musi zawsze istnieć albo mamy
dodatkowy zestaw
procedur dla MA, jedne z kolumną body drugie bez. Bo inaczej tego nie
zapiszemy.
Ewentualnie kolumnę w bazie zostawić a w aplikacji pisać do niej NULL
jak feature jest
wyłączony, ale.. wtedy włączenie FTS nie zadziała dla starych wiadomości.
No ja sobie wyobrazam to tak ze mamy jedna podstawowa definicje baz dany
i indeksow, plus jakies dodatkowe, opcjonalne definicje ktore moga byc
wlaczone lub nie.
W praktyce to moze wygladac tak ze klient wykupuje add-on, a my po
naszej stronie robimy upgrade bazy danych do wiekszego RDS oraz dodajemy
dodatkowe definicje (indeksy).
@Wojtek - to byloby zadanie dla Ciebie. Wydzielenie tego indeksy (lub
jeszcze innych jesli ma to sens) i do osobnego, opcjonalnego schema.
Oraz zastanowienie sie i zaimplementowanie takiego upgrade'u na AWS EB.
Re: [DEVPL] AWS i tigase.org @13/05/2020 15:54
No ja sobie wyobrazam to tak ze mamy jedna podstawowa definicje baz dany i indeksow, plus jakies dodatkowe, opcjonalne definicje ktore moga byc wlaczone lub nie.
W praktyce to moze wygladac tak ze klient wykupuje add-on, a my po naszej stronie robimy upgrade bazy danych do wiekszego RDS oraz dodajemy dodatkowe definicje (indeksy).
@Wojtek - to byloby zadanie dla Ciebie. Wydzielenie tego indeksy (lub jeszcze innych jesli ma to sens) i do osobnego, opcjonalnego schema. Oraz zastanowienie sie i zaimplementowanie takiego upgrade'u na AWS EB.