データベースを必要とする、MS Visual C#Express(必要に応じて標準にアップグレードしたい)を使用してビルドするアプリケーション。
SQL Server Compactに夢中になりました-自分のアプリケーションをコンピューターにインストールする人がSQL Server全体またはそのようなものをインストールすることを望まないためです。エンドユーザーがインストールするのを可能な限り簡単にする必要があります。
だから、テーブルの列でできることには限界があるように思えるまで、私はみんな気が狂っていました。新しいデータベースを作成し、テーブルを作成し、列を作成するときに「テキスト」データ型はないようです-「ntext」と呼ばれる255文字に制限されているように見えます。 「int」は4に制限されているようです(11が必要でした)。そして、「auto_increment」機能はないようです。
これらは私が一緒に暮らさなければならない本当の制限ですか? (または、「標準」ではなく「エクスプレス」を使用しているためです)。これらが実際の制限である場合、要件を満たす他のデータベースオプションは何ですか? (ユーザーが大物であるための簡単なインストール-エンドユーザーはコンピューターの平均的なユーザーであり、複雑な場合はアプリケーションにイライラすることを想定しています)
-アディーナ
PS:データベースデータもエンドユーザーに対して暗号化する必要があります。データベーステーブルに直接アクセスできるようにしたくありません。
PPS。私は読みました: http://www.Microsoft.com/Sqlserver/2005/en/us/compact.aspx そしてこれらの特定の制限に関する議論を見ませんでした
暗号化についてはわかりませんが、おそらく次のリンクが役立つでしょう。
http://msdn.Microsoft.com/en-us/library/ms171955.aspx
残りについては:
「テキスト」と「auto_increment」は、Accessを思い出させます。 SQL Server Compactは、SQL Serverのserverエディションとアップグレード互換であると想定されています。コンパクトデータベースで使用されるクエリとテーブルは、完全な変更なしのデータベース。それを念頭に置いて、最初にAccess名ではなく SQL Serverの種類と名前 を確認する必要があります。この場合はvarchar(max)
、bigint
、およびidentity
列。
残念ながら、Compact Editionにはまだvarchar(max)型がないため、varchar(max)に関してこれが失敗することがわかります。うまくいけば、彼らはすぐにそれを修正します。ただし、見ていたntext型は255バイト以上をサポートしています:230 実際、5億文字以上になります。
最後に、bigintはストレージに8バイトを使用します。 11を要求しましたが、ここで、ストレージサイズが使用可能な10進数の桁数を示していると混同される可能性があります。これは間違いです。 8バイトのストレージにより、最大2つの値が可能64、11桁以上の数字に対応します。その数のアイテムがある場合は、おそらくサーバークラスのデータベースが必要です。数字の面で本当に考えたい場合は、numeric
タイプも用意されています。
いくつかの、うまくいけば役立つコメント:
1つ目-書き込み中にデータベース全体をロックする必要がある場合( http://www.sqlite.org/faq.html#q6 )、おそらくより重要な場合は.NetでSQLiteを使用しないでくださいアプリケーションは、スレッドをサポートするために再コンパイルする必要があるまで、スレッドセーフではありません( http://www.sqlite.org/faq.html#q6 )
現在のプロジェクトの代替として、Scimore DBを調べました(ADO.Netプロバイダーが組み込まれたバージョンがあります: http://www.scimore.com/products/embedded.aspx ) LINQ To SQLをO/RMとして使用するため、SQL Server CEを使用する必要がありました。
自動インクリメント(自動キーインクリメントを参照している場合)は、常にそれがそうであったものです-例の表:
-テーブルユーザー
CREATE TABLE Tests (
Id **int IDENTITY(1,1) PRIMARY KEY NOT NULL,**
TestName nvarchar(100) NOT NULL,
TimeStamp datetime NOT NULL
)
GO
テキストサイズに関しては、答えられたと思います。
Microsoft technetからの暗号化に関する情報へのリンクは次のとおりです:( http://technet.Microsoft.com/en-us/library/ms171955.aspx )
これが少し役立つことを願っています...
次の2つの要因に注意する必要がありました。
キーを十分に隠すことができて、それを回復する努力が情報の価値に見合わない場合があります。 Windowsには、便利なマシンとユーザーのローカル暗号化ルーチンがあります。しかし、ユーザーのコンピューターに隠されたデータをユーザーが見つけられないという強い要件がある場合(ただし、プログラムはそうなります)、再設計する必要があります-その保証は単に達成できません。
ntext
は非常に大きなテキストデータをサポートします( [〜#〜] msdn [〜#〜] を参照-これはCompact 4.0用ですが、同じことが、言及しているデータ型の3.5にも当てはまります)。
int
は数値データ型であるため、_4
_のサイズは4バイト/ 32ビットストレージ(–2,147,483,648〜2,147,483,647)を意味します。単一の列に11バイトのデータを格納する場合は、サイズが11のvarbinary
タイプを使用します。
SQL Serverの世界での列の自動インクリメントは、IDENTITY
キーワードを使用して行われます。これにより、行にデータを挿入するときにSQL Serverによって列の値が自動的に決定され、他の行との衝突が防止されます。
SQL Compactでデータベースを作成するときにパスワードを設定したり、データベースを暗号化して、ユーザーがアプリケーションに直接アクセスできないようにすることもできます。 MSDNの データベースの保護を参照してください 。
上記のすべての項目は、SQL Serverの使用方法を理解している限り、実際には制限事項ではありません。
そうは言っても、SQL Compactにはいくつかの制限があります。
NVARCHAR(MAX)
のサポートなしNTEXT
はこれに対してうまく機能しますVIEW
sまたはPROCEDURE
s のサポートなしSQL CEは私にとってパズルです。さらに別のSQLデータベースプラットフォームが本当に必要でしたか?そして、MSのモバイルプラットフォームをターゲットにした過去数年で3番目です。 SQL Serverと何らかのテクノロジーを共有しているわけではありません-私が知る限り、それはゼロからの新しいテクノロジーです。
私は試してみましたが、SQLiteとCodebaseの両方でより成功しました。
編集: ここにリストがあります (多くの)違い。
さまざまなSQL Server Compactエディションを数回使用しましたが、モバイルプラットフォーム上のデータキャプチャリポジトリとしてのみ使用しました。サーバーデータベースとの同期に適しているため、このようなシナリオは間違いなくオプションの選択肢です。
ただし、それ以上のことを行い、アプリケーションのプライマリデータベースとして機能する必要がある場合は、SQLLiteがおそらくより良いオプションであることをお勧めします。完全に堅牢で、広くサポートされ、あらゆる種類の場所で見つかります例)しかし、驚くほどの能力があります(仮想現実シミュレータ OpenSim はデフォルトのデータベースとして使用します) 他の多く (Microsoftを含む)があります。
この投稿( http://www.nelsonpires.com/web-development/Microsoft-webmatrix-the-dawn-of-a-new-era/ )によると、データベースファイルでは、読み取り/書き込みごとに1つのプロセスのみがアクセスできます。その結果、ファイルへの排他的アクセスが必要になります。また、256接続に制限され、ファイル全体をメモリにロードする必要があります。そのため、SQLサーバーのコンパクト化は、サイトが成長したときにサイトに適さない場合があります。
ここでは、SQL CEの代替として VistaDB でチャイムする必要があります。
VistaDBは暗号化(Blowfish)をサポートしており、NTEXTと同様にTEXTもサポートしています(FTSインデックスを含む)。
はい、上記の投稿は、SQL Serverタイプを実際に一致させるために見る必要があるという点で正しいです。VistaDBはSQL Serverタイプも使用します(実際には、SQL CEがサポートする以上のものをサポートしています。XMLのみが欠落しています)。
他の VistaDBとSQL CEの比較 を見るには、比較ページにアクセスしてください。詳細については、SO thread on VistaDBの利点 も参照してください。
(完全開示-私はVistaDBの所有者なので、偏見があるかもしれません)
制約があります...ジョエルは詳細に取り組んだようです。 SQL CEは、モバイル開発に本当に適しています。ほとんどの「組み込み」データベースソリューションには同様の制約があります。チェックアウト
TEXT
フィールドの文字制限なしINTEGER PRIMARY KEY
列でのみ自動インクリメント