Typowym sposobem na to jest posiadanie tabeli „właściwości”, która jest identyczna z plikiem właściwości. Tutaj możesz przechowywać wszystkie stałe aplikacji lub nie tak stałe rzeczy, które po prostu musisz mieć pod ręką.
Następnie możesz pobrać informacje z tej tabeli, gdy ich potrzebujesz. Podobnie, gdy stwierdzisz, że masz inne ustawienia do zapisania, możesz je dodać. Oto przykład:
property_entry_table
[id, scope, refId, propertyName, propertyValue, propertyType]
1, 0, 1, "COMPANY_INFO", "Acme Tools", "ADMIN"
2, 0, 1, "SHIPPING_ID", "12333484", "ADMIN"
3, 0, 1, "PAYPAL_KEY", "2143123412341", "ADMIN"
4, 0, 1, "PAYPAL_KEY", "123412341234123", "ADMIN"
5, 0, 1, "NOTIF_PREF", "ON", "ADMIN"
6, 0, 2, "NOTIF_PREF", "OFF", "ADMIN"
W ten sposób możesz przechowywać dane, które posiadasz oraz dane, które będziesz mieć w przyszłym roku, o których jeszcze nie wiesz :).
W tym przykładzie twój zakres i refId mogą być używane do wszystkiego, co chcesz na zapleczu. Więc jeśli propertyType „ADMIN” ma zakres 0 refId 2, wiesz, jakie to preferencje.
Typ nieruchomości przydaje się, gdy pewnego dnia będziesz musiał przechowywać tutaj również informacje niebędące administratorami.
Pamiętaj, że nie powinieneś przechowywać danych koszyka w ten sposób ani wyszukiwać w tej sprawie. Jeśli jednak dane są specyficzne dla systemu , z pewnością możesz użyć tej metody.
Na przykład: jeśli chcesz przechowywać swoją DATABASE_VERSION , użyłbyś takiej tabeli. W ten sposób, gdy musisz zaktualizować aplikację, możesz sprawdzić tabelę właściwości, aby zobaczyć, jaką wersję oprogramowania ma klient.
Chodzi o to, że nie chcesz tego używać do rzeczy, które dotyczą koszyka. Utrzymuj logikę biznesową w dobrze zdefiniowanych tabelach relacyjnych. Tabela właściwości służy tylko do informacji systemowych.