Una forma común de hacer esto es tener una tabla de "propiedades" simétrica a un archivo de propiedades. Aquí puede almacenar todas las constantes de su aplicación, o cosas no tan constantes que solo necesita tener a mano.
Luego puede obtener la información de esta tabla según lo necesite. Del mismo modo, cuando encuentre que tiene otra configuración para guardar, puede agregarla. Aquí hay un ejemplo:
propiedad_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"
De esta manera, puede almacenar los datos que tiene y los datos que tendrá el próximo año y que aún no conoce :).
En este ejemplo, su alcance y refId se pueden usar para lo que desee en el back-end. Entonces, si propertyType "ADMIN" tiene un ámbito 0 refId 2, usted sabe qué preferencia es.
El tipo de propiedad viene cuando, algún día, también necesita almacenar información no administrativa aquí.
Tenga en cuenta que no debe almacenar los datos del carrito de esta manera, o búsquedas para el caso. Sin embargo, si los datos son específicos del sistema , entonces ciertamente puede usar este método.
Por ejemplo: si desea almacenar su DATABASE_VERSION , usaría una tabla como esta. De esa manera, cuando necesite actualizar la aplicación, puede consultar la tabla de propiedades para ver qué versión de su software tiene el cliente.
El punto es que no desea usar esto para cosas que pertenecen al carrito. Mantenga su lógica empresarial en tablas relacionales bien definidas. La tabla de propiedades es solo para información del sistema.