J'essaie de voir ce que la meilleure façon de stocker de grandes quantités de texte (plus de 255 caractères) au cacao serait. Être un grand fan de données de base, je supposerais qu'il y aurait un moyen efficace de le faire. Cependant, je me sens comme «chaîne» est le mauvais type de données pour ce type de chose. Quelqu'un a-t-il des informations sur cela? Je ne vois pas une option pour blob dans les données de base
3 Réponses :
Je recommanderais une lecture d'Apple Guide de programmation de données de base (spécifiquement la section "Performance de données de base"). Cela mentionne spécifiquement les blobs (voir la section "Grands objets de données (blobs)") et donne quelques instructions, bien que vagues,.
Le type de données BLOB est appelé "Données binaires" dans les données de base. Comme Middaparka a souligné, le Programmation de données de base Le guide offre des conseils sur la manière de traiter des données binaires dans les données de base. Selon vos besoins, une alternative à l'utilisation des blobs serait de stocker simplement des références à des fichiers sur disque.
Allait mentionner l'option "sur le disque, référence dans dB", mais il aura besoin de s'assurer manuellement que les ressources sur disque sont éliminées lorsque l'objet est supprimé, car les données de base ne supprimeront évidemment que la référence.
Facilement manipulé avec une sous-classe de base NsmanieDObject pour l'entité, répondant aux méthodes insert / sauvegardier / Supprimer / Supprimer. J'utilise cette approche pour créer des "talons" projecteurs d'une base de données centrale similaire iTunes, qui est géré par des données de base + SQLite Store Type.
Eh bien, vous ne pouvez pas très bien compresser le texte ou le stocker comme un binaire qui doit être traduit, sinon vous abandonnerez la vitesse de requête de SQLite (car toutes toutes les enregistrements de données à encodage de texte-binaire) doivent être lus. dans la mémoire, traduit / décompressé, puis recherché). Sinon, vous devez miroir (et maintenir) la représentation du texte uniquement dans votre magasin de données de base aux côtés des éléments plus complets.
Que diriez-vous d'une solution hybride? Les données de base stockent tous sauf le texte actuel; Le texte lui-même est archivé une donnée de fichiers-parenseurs sur le système de fichiers sur le système de fichiers. Chaque fichier nommé pour son identifiant unique dans le magasin de données de base. Ainsi, une recherche pourrait faire deux choses (en arrière-plan, bien sûr): recherchez le magasin de données de base pour des éléments tels que des titres, des dates, etc. Recherchez les fichiers (peut-être même avec des projecteurs) pour la recherche de contenu. S'il existe une correspondance de recherche de fichiers, son nom de fichier est utilisé pour rechercher l'enregistrement correspondant dans les données principales à afficher dans l'interface utilisateur de votre application.
Cela vous permet d'utiliser vos critères de recherche internes spécifiques à l'application et la recherche asynchrone de projecteurs. C'est un peu plus de travail, accordé, mais si vous parlez de beaucoup de texte, je ne peux pas penser à une meilleure façon.
Merci pour le commentaire Josh! Je suis juste curieux - la documentation décrit l'utilisation de binaires pour de grandes quantités (KB- à plusieurs MB) afin de faire mal à utiliser cela? Il semble tout simplement plus pratique de stocker les données des données de base pour la recherche et l'indexation et de la fiabilité juste?
Vous ne pourrez pas rechercher de texte à l'intérieur des informations binaires directement dans le magasin SQLite. Chaque "enregistrement" (chaque instance de l'entité donnée) devrait être lu dans, décodé (cependant est approprié d'obtenir vos informations de texte), puis recherchez dans la mémoire. Très inefficace.
En prime, l'approche de liens-to-externes-fichiers minimise le risque d'un mauvais octet Host de votre document complet / base de données. Un gros morceau de viande (le texte) est toujours en sécurité même si la base de données est en désaccord.
Avez-vous déjà essayé d'utiliser Nstring? Nstring et les données de base ne doivent avoir aucun problème de manipulation des chaînes beaucoup plus importantes que 255 caractères.
@Joe Blow Core Data est soutenu par SQLite. I.E.: Les données de base sont "un travail de base de données".
@Joe souffle et vous savez que l'OP ne nécessite pas l'orje comme des capacités de données de base en fonction de quoi? (Autre que votre propre hypothèse.)
Nstring n'est pas si bon IDE si vous souhaitez stocker une grande quantité de texte. Vous pourriez un code d'erreur1660 .