Une manière courante de faire ceci est d'avoir une table de «propriétés» semblable à un fichier de propriétés. Ici, vous pouvez stocker toutes les constantes de votre application, ou des choses pas si constantes dont vous avez juste besoin.
Vous pouvez ensuite récupérer les informations de ce tableau selon vos besoins. De même, comme vous constatez que vous avez un autre paramètre à enregistrer, vous pouvez l'ajouter. Voici un exemple:
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"
De cette façon, vous pouvez stocker les données dont vous disposez et les données que vous aurez l'année prochaine et que vous ne connaissez pas encore :).
Dans cet exemple, votre scope et refId peuvent être utilisés pour tout ce que vous voulez sur le back-end. Donc, si propertyType "ADMIN" a une portée 0 refId 2, vous savez de quelle préférence il s'agit.
Le type de propriété entre en jeu quand, un jour, vous devez également stocker des informations non-administrateur ici.
Notez que vous ne devez pas stocker les données du panier de cette façon, ni les recherches d'ailleurs. Cependant, si les données sont spécifiques au système , vous pouvez certainement utiliser cette méthode.
Par exemple: si vous souhaitez stocker votre DATABASE_VERSION , vous utiliserez une table comme celle-ci. De cette façon, lorsque vous devez mettre à niveau l'application, vous pouvez consulter le tableau des propriétés pour voir quelle version de votre logiciel le client possède.
Le fait est que vous ne voulez pas l'utiliser pour des choses qui concernent le chariot. Gardez votre logique métier dans des tables relationnelles bien définies. Le tableau des propriétés est uniquement destiné aux informations système.