Je construis une application mobile J'utilise php & mysql pour écrire une API de backend - repos.
Si je dois stocker environ 50-60 valeurs booléennes dans une table appelée "Rapports" (les utilisateurs doivent vérifier les choses sous une forme) dans mon application mobile, je stocke les valeurs (0/1) dans un tableau simple. Dans ma table MySQL, dois-je créer une colonne différente pour chaque valeur booléenne ou suffit-il si j'utilise simplement une chaîne ou une chaîne pour la stocker comme un "numéro" comme "110101110110111 ..."?
Je reçois et mettez les données avec JSON.
Mise à jour 1: Tout ce que je dois faire, c'est vérifier si tout est 1, si l'un d'entre eux est 0, c'est un "problème". En 2 ans, ce tableau aura environ 15 000 à 20 000 rangées, il doit être très rapide et aussi de l'espace possible que possible.
Mise à jour 2: En termes de vitesse que la solution est plus rapide? Faire des colonnes séparées vs stockez-la dans une chaîne / type binaire. Et si je dois vérifier lesquels sont les 0? Est-ce une excellente solution si je le stocke comme un "nombre" dans une colonne et si ce n'est pas "111...111", envoyez-le à l'application mobile comme JSON où j'étilise la valeur et analysez-la sur le périphérique de l'utilisateur? Disons que je dois gérer des rangées de 50k.
Merci d'avance.
3 Réponses :
Une colonne séparée par valeur est plus flexible lorsqu'il s'agit de rechercher.
Une table de clé / valeur distincte est plus flexible si différentes lignes ont des collections différentes de valeurs booléennes.
et, si < / p>
Ensuite, utilisez des chaînes de texte comme '1001010010', etc., c'est un bon moyen de les stocker. Vous pouvez rechercher comme ceci pour trouver les lignes dont vous avez besoin. Vous pouvez utiliser une colonne binaire avec un bit par drapeau. Mais votre table sera plus facile à utiliser pour les requêtes décontractées et l'inspection du globe oculaire si vous utilisez du texte. Les économies d'espace de l'utilisation binaire au lieu de charme ne seront pas significatives avant de commencer à stocker plusieurs millions de lignes. edit Il faut dire: chaque fois que j'ai construit Quelque chose comme ça avec des tableaux d'attributs booléens, j'ai été déçu tard à quel point il s'est inflexible pour être. Par exemple, supposons que c'était un catalogue d'ampoules. Au tournant du millénaire, les drapeaux booléens auraient pu être des trucs comme puis, les choses changent et je me trouve besoin d'avoir besoin de drapeaux plus booléens, comme, < Pré> xxx etc. Tout à coup, mes types de données ne sont pas assez gros pour tenir ce dont j'en ai besoin pour tenir. Quand j'ai écrit "Votre liste de valeurs booléenses est plus ou moins statique", je voulais dire que vous n'attendez pas raisonnablement avoir quelque chose comme les caractéristiques de l'ampoule de lumière changeant pendant la durée de vie de votre application. Donc, une table d'attributs distincts pourrait une meilleure solution. Il aurait ces colonnes: Ceci est finalement flexible. Vous pouvez simplement ajouter de nouveaux drapeaux. Vous pouvez les ajouter aux éléments existants ou aux nouveaux éléments, à tout moment de la durée de vie de votre application. Et chaque article n'a pas besoin de la même collection de drapeaux. Vous pouvez écrire "quels éléments ont des faux attributs?" Requête comme ceci: mais, vous devez faire attention car la requête "Quels éléments a des attributs manquants" est beaucoup plus difficile à écrire.
Qu'en est-il du bit (n) au lieu de la chaîne?
Merci pour la réponse. «Chaque fois que j'ai construit quelque chose comme celui-ci avec des tableaux d'attributs booléens, j'ai été déçu tard" Pouvez-vous me donner une meilleure solution? Je suis ouvert pour apprendre de nouvelles choses.
Certainement d'une nouvelle table, il est également normalisé. en.wikipedia.org/wiki/...
Pour votre objectif spécifique, lorsque tout drapeau zéro est un problème (une exception) et la plupart des entrées (comme 99%) seront "1111 ... 1111", je ne vois aucune raison de les stocker tous. Je préférerais créer une table séparée qui stocke uniquement des drapeaux non contrôlés. La table pourrait ressembler à: non peaux_flags (user_id, flag_id) . Dans une autre table, vous stockez vos définitions de drapeau: drapeaux (flag_id, flag_name, flag_description) . Votre rapport est aussi simple que SELECT * à partir de non cochecked_flags .
Vous mai Obtenez une meilleure recherche d'utiliser des colonnes dédiées, pour chaque booléen, mais la cardinalité est médiocre et même si vous indexez chaque colonne, cela impliquera un peu de traversée ou de balayage. < / p>
Si vous recherchez simplement des valeurs hauteurs 0xFFF .... Puis définitivement bitmap, cela résout votre problème de cardinalité (par op Update). Ce n'est pas comme si vous vérifiez la parité ... L'arborescence sera cependant fortement asymétrique à des valeurs élevées si cela est normal et peut créer une pointe de chaude sujette à la séparation des nœuds sur des inserts.
La cartographie des bits et l'utilisation de masques de l'opérateur bitwise permettront d'économiser de l'espace mais devront être alignés sur un octet afin qu'il puisse y avoir une "pointe" inutilisée (provisioning pour les champs futurs peut-être), de sorte que le masque doit donc être de longueur maintenue ou champ rembourré avec 1s.
Il ajoutera également une complexité à votre architecture, qui peut nécessiter une codage sur mesure, des normes sur mesure.
Vous devez effectuer une analyse sur l'importance de toute recherche (vous ne vous attendez peut-être pas normalement à la recherche de tous. ou même à tous les champs distincts).
Il s'agit d'une stratégie très courante pour dénormaliser les données et également pour la demande de service de numérisation de clients spécifiques. (Où certains dépêps sont plus gros que d'autres pour la même transaction).
Si vous aurez besoin de rechercher (en utilisant des trucs comme
où bool_a et non bool_b ) sur les valeurs de ces indicateurs, cela vous pousse à les stocker dans leurs propres colonnes. Mais vous ne nous avez pas dit comment votre application doit utiliser ces données.Vous avez raison. Tout ce que je dois faire, c'est vérifier si tout est 1, si l'un d'entre eux est 0 alors c'est un "problème". En 2 ans, cette table aura environ 15 000 à 20 000 rangées, elle doit être très rapide et aussi de l'économie de place que possible.
Vous pourriez aller avec des drapeaux, si vous êtes sûr que vous n'avez pas à ajouter des trucs au milieu. Vous pouvez utiliser le type binaire pour cela.
En termes de vitesse quelle solution est plus rapide? Faire des colonnes séparées vs stockez-la dans une chaîne / type binaire. Et si je dois vérifier lesquels sont les 0? Est-ce une excellente solution si je le stocke comme un "nombre" dans une colonne et si ce n'est pas "111...111", envoyez-le à l'application mobile comme JSON où j'étilise la valeur et analysez-la sur le périphérique de l'utilisateur? Disons que je dois faire face à des rangées de 10k.
Si vous mettez chaque valeur booléenne dans sa propre colonne, votre application nécessitera des modifications de la base de données chaque fois que vous ajoutez un nouveau rapport (en supposant que vous ajoutez de nouveaux rapports). Peut-être devriez-vous envisager de stocker les données dans un format long et maigre (voir STATMETHODS.NET/MANAGE/RESHAPE .html pour voir les formats «larges» vs 'Long' pour le même jeu de données).
S'il vous plaît considérer éditer votre question pour inclure les clarifications que vous avez données dans les commentaires.
15-20K lignes est rien . MySQL peut traiter rapidement des milliards de lignes si elles sont bien indexées.
J'ai édité ma question merci pour les réponses.
Je vous suggère de diviser la table et de stocker chacun des champs booléens dans un champ distinct. Ce sera plus lisible et vous évitera des problèmes plus tard. Ne vous inquiétez pas d'environ 20 000. Nous travaillons avec des tables comportant entre 40 et 200 millions d'enregistrements et MySQL les gère tout simplement bien.