L'application que je souhaite créer à l'aide de MS Visual C # Express (je suis prêt à passer à la norme si cela devient nécessaire) qui a besoin d'une base de données.
J'étais complètement excité par SQL Server Compact - parce que je ne veux pas que les gens qui installeraient mon application sur leurs ordinateurs aient à installer l'ensemble de SQL Server ou quelque chose comme ça. Je veux que ce soit aussi simple que possible pour l'utilisateur final à installer.
J'ai donc été très excité jusqu'à ce qu'il semble qu'il y ait des limites à ce que je peux faire avec les colonnes de mes tables. J'ai créé une nouvelle base de données, créé une table et quand je suis allé créer des colonnes, il semble qu'il n'y ait pas de type de données "texte" - juste quelque chose appelé "ntext" qui semble être limité à 255 caractères. "int" semble être limité à 4 (je voulais 11). Et il ne semble pas y avoir de fonctionnalité "auto_increment".
Est-ce là les vraies limitations avec lesquelles je devrais vivre? (Ou est-ce parce que j'utilise "Express" et non "Standard"). Si ce sont les vraies limitations, quelles sont mes autres options de base de données qui répondent à mes exigences? (installation facile pour l'utilisateur étant le biggie - je suppose que mon utilisateur final n'est qu'un utilisateur moyen d'ordinateurs et si c'est compliqué, cela deviendrait frustrant avec mon application)
-Adeena
PS: Je souhaite également que mes données de base de données soient cryptées pour l'utilisateur final. Je ne veux pas qu'ils puissent accéder directement aux tables de base de données.
PPS. J'ai lu: http://www.Microsoft.com/Sqlserver/2005/en/us/compact.aspx et je n'ai pas vu de discussion sur ces limitations particulières
Je ne suis pas sûr du cryptage, mais vous trouverez probablement ce lien utile:
http://msdn.Microsoft.com/en-us/library/ms171955.aspx
Quant au reste:
"Texte" et "incrémentation automatique" me rappellent Access. SQL Server Compact est censé être compatible avec la mise à niveau vers les éditions du serveur de SQL Server, dans la mesure où les requêtes et les tables utilisées dans votre base de données compact doivent être transférées vers une version complète base de données sans modification. Dans cet esprit, vous devez d'abord regarder les types et noms SQL Server plutôt que les noms Access: dans ce cas, à savoir varchar(max)
, bigint
et identity
colonnes.
Malheureusement, vous remarquerez que cela échoue en ce qui concerne varchar (max), car Compact Edition n'a pas encore le type varchar (max). J'espère qu'ils régleront cela bientôt. Cependant, le type ntext que vous regardiez prend en charge beaucoup plus de 255 octets: 230 en fait, ce qui représente plus de 500 millions de caractères.
Enfin, bigint utilise 8 octets pour le stockage. Vous en avez demandé 11. Cependant, je pense que vous pouvez être confus ici que la taille de stockage indique le nombre de chiffres décimaux disponibles. Ce n'est certainement pas le cas. 8 octets de stockage permettent des valeurs jusqu'à 264, qui pourra accueillir beaucoup plus de 11 chiffres. Si vous avez autant d'éléments que vous voulez probablement une base de données de classe serveur de toute façon. Si vous voulez vraiment penser en termes de chiffres, un type numeric
est également fourni.
Quelques commentaires, je l'espère utiles:
1er - n'utilisez pas SQLite sauf si vous aimez avoir à verrouiller toute la base de données pendant les écritures ( http://www.sqlite.org/faq.html#q6 ) et peut-être plus important encore dans un .Net application, il n'est PAS sûr pour les threads ou plus au point qu'il doit être recompilé pour prendre en charge les threads ( http://www.sqlite.org/faq.html#q6 )
En tant que remplaçant pour mon projet actuel, j'ai examiné Scimore DB (ils ont une version intégrée avec le fournisseur ADO.Net: http://www.scimore.com/products/embedded.aspx ) mais j'avais besoin d'utiliser LINQ To SQL comme O/RM, j'ai donc dû utiliser Sql Server CE.
L'incrémentation automatique (si vous faites référence à l'incrémentation automatique des touches) est ce qu'elle a toujours été - exemple de tableau:
- Utilisateurs de table
CREATE TABLE Tests (
Id **int IDENTITY(1,1) PRIMARY KEY NOT NULL,**
TestName nvarchar(100) NOT NULL,
TimeStamp datetime NOT NULL
)
GO
En ce qui concerne la taille du texte, je pense qu'il a été répondu.
Voici un lien vers des informations sur le cryptage à partir de Microsoft Technet: ( http://technet.Microsoft.com/en-us/library/ms171955.aspx )
J'espère que ça aide un peu....
J'ai dû jouer sur deux facteurs:
Vous pourrez peut-être masquer la clé suffisamment bien pour que l'effort de récupération ne vaille pas la valeur de l'information. Windows a des routines de chiffrement locales soignées pour les machines et les utilisateurs pour vous aider. Mais si votre conception exige fortement qu'un utilisateur ne trouve jamais de données que vous avez cachées sur son ordinateur (mais votre programme le fera), vous devez repenser - cette garantie ne peut tout simplement pas être accomplie.
ntext
prend en charge des données texte très volumineuses (voir MSDN - c'est pour Compact 4.0, mais il en va de même pour 3.5 pour les types de données que vous êtes mentionner).
int
est un type de données numérique, donc la taille de 4
signifie 4 octets/32 bits de stockage (–2 147 483 648 à 2 147 483 647). Si vous avez l'intention de stocker 11 octets de données dans une seule colonne, utilisez le type varbinary
avec une taille de 11.
L'incrémentation automatique des colonnes dans le monde SQL Server s'effectue à l'aide du mot clé IDENTITY
. Cela entraîne la détermination automatique de la valeur de la colonne par SQL Server lors de l'insertion de données dans une ligne, empêchant les collisions avec d'autres lignes.
Vous pouvez également définir un mot de passe ou crypter la base de données lors de sa création dans SQL Compact pour empêcher les utilisateurs d'accéder directement à votre application. Voir Sécurisation des bases de données sur MSDN .
Tous les éléments que vous mentionnez ci-dessus ne sont pas vraiment des limitations, car ils comprennent comment utiliser SQL Server.
Cela dit, il existe certaines limites à SQL Compact.
NVARCHAR(MAX)
NTEXT
fonctionne très bien pour celaVIEW
s ou PROCEDURE
s SQL CE est un casse-tête pour moi. Avions-nous vraiment besoin d'une autre plateforme de base de données SQL différente? Et c'est la troisième au cours des dernières années ciblée sur les plates-formes mobiles de MS ... Je n'aurais pas beaucoup confiance que ce sera la dernière. Il ne partage pas grand-chose ou pas de technologie avec SQL Server - c'est une nouvelle à partir de zéro pour autant que je sache.
Je l'ai essayé, puis j'ai plus de succès avec SQLite et Codebase.
EDIT: Voici une liste des (nombreuses) différences.
J'ai utilisé les différentes éditions de SQL Server Compact à quelques reprises, mais uniquement en tant que référentiels de capture de données sur des plates-formes mobiles - où cela fonctionne bien pour la synchronisation avec une base de données de serveur, et avec ce genre de scénario est sans aucun doute le choix facultatif.
Cependant, si vous avez besoin de quelque chose pour faire plus que cela et agir comme une base de données principale pour votre application, je suggérerais que SQLLite soit probablement la meilleure option, il est complètement solide, largement pris en charge et trouvé dans toutes sortes d'endroits (utilisé sur l'iPhone pour exemple) mais est étonnamment capable (le simulateur de réalité virtuelle OpenSim l'utilise comme base de données par défaut) et il y en a beaucoup d'autres (y compris Microsoft).
Selon cet article ( http://www.nelsonpires.com/web-development/Microsoft-webmatrix-the-dawn-of-a-new-era/ ), il dit que parce qu'il utilise un fichier de base de données, un seul processus peut y accéder pour chaque lecture/écriture et, par conséquent, il a besoin d'un accès exclusif au fichier, il est également limité à 256 connexions et le fichier entier devra très probablement être chargé en mémoire. Ainsi, SQL Server compact peut ne pas être bon pour votre site lorsqu'il se développe.
Je dois également carillon ici avec VistaDB comme alternative à SQL CE.
VistaDB prend en charge le cryptage (Blowfish), il prend également en charge TEXT ainsi que NTEXT (y compris les index FTS sur eux).
Et oui, le post ci-dessus est correct dans la mesure où vous devez regarder les types SQL Server pour vraiment les faire correspondre, VistaDB utilise également les types SQL Server (nous prenons en charge plus que SQL CE; il ne manque que XML).
Pour voir d'autres comparaisons entre VistaDB et SQL CE visitez la page de comparaison. Voir également le fil SO sur Avantages de VistaDB pour plus d'informations.
(Divulgation complète - je suis le propriétaire de VistaDB, donc je peux être partial)
Il y a des contraintes ... Joel semble avoir abordé les détails. SQL CE est vraiment orienté vers le développement mobile. La plupart des solutions de bases de données "embarquées" ont des contraintes similaires. Check-out
TEXT
limite de caractères de champINTEGER PRIMARY KEY
colonne