programing

SQL Server Compact의 제한 사항은 무엇입니까?

nicescript 2021. 1. 15. 07:52
반응형

SQL Server Compact의 제한 사항은 무엇입니까? (또는-MS 플랫폼에서 사용할 데이터베이스를 어떻게 선택합니까?)


데이터베이스가 필요한 MS Visual C # Express (필요한 경우 Standard로 업그레이드 할 의향이 있음)를 사용하여 구축하려는 응용 프로그램입니다.

저는 SQL Server Compact에 대해 열광했습니다. 컴퓨터에 내 응용 프로그램을 설치하는 사람들이 SQL Server 전체를 설치하거나 그와 비슷한 것을 설치하지 않아도되기를 원하기 때문입니다. 최종 사용자가 가능한 한 쉽게 설치할 수 있기를 바랍니다.

그래서 내 테이블의 열로 할 수있는 작업에 제한이있는 것처럼 보일 때까지 나는 모두 흥분했습니다. 새 데이터베이스를 만들고 테이블을 만들고 열을 만들러 갔을 때 "text"데이터 유형이없는 것처럼 보였습니다. 255 자로 제한되는 "ntext"라고하는 것뿐입니다. "int"는 4로 제한되는 것 같습니다 (11을 원했습니다). 그리고 "auto_increment"기능이없는 것 같습니다.

이것이 내가 살아야 할 진정한 한계입니까? (또는 "Standard"가 아닌 "Express"를 사용하고 있기 때문입니다.) 이것이 실제 제한이라면 내 요구 사항을 충족하는 다른 데이터베이스 옵션은 무엇입니까? (사용자를위한 쉬운 설치가 중요합니다. 최종 사용자가 컴퓨터의 일반 사용자 일 뿐이며 복잡하면 응용 프로그램에 실망 할 것입니다.)

-아디나

추신 : 또한 데이터베이스 데이터가 최종 사용자에게 암호화되기를 원합니다. 나는 그들이 데이터베이스 테이블에 직접 접근하는 것을 원하지 않는다.

PPS. 나는 http://www.microsoft.com/Sqlserver/2005/en/us/compact.aspx를 읽었 으며 이러한 특정 제한에 대한 토론을 보지 못했습니다.


암호화에 대해 잘 모르겠지만이 링크가 도움이 될 것입니다.
http://msdn.microsoft.com/en-us/library/ms171955.aspx

나머지는
"Text"와 "auto_increment"가 Access를 상기시킵니다. SQL Server Compact는 SQL Server의 서버 버전과 업그레이드 호환 되어야합니다. 압축 데이터베이스에 사용되는 쿼리와 테이블은 수정없이 전체 데이터베이스로 전송되어야합니다. 마음에, 먼저 살펴 봐야한다는와 SQL 서버 유형 및 이름 액세스 이름보다는 :이 경우, 즉 varchar(max), bigintidentity열.

불행히도 Compact Edition에는 아직 varchar (max) 유형이 없기 때문에 varchar (max)와 관련하여 이것이 실패한다는 것을 알 수 있습니다. 곧 수정 될 것입니다. 그러나보고있는 ntext 유형은 255 바이트 이상을 지원합니다. 실제로는 2, 30 , 즉 5 억 개 이상의 문자에 해당합니다.

마지막으로 bigint는 저장에 8 바이트를 사용합니다. 11을 요청하셨습니다. 그러나 여기에서 스토리지 크기가 사용 가능한 10 진수 숫자를 나타내는 것으로 혼동 될 수 있습니다. 이것은 확실히 사실이 아닙니다. 8 바이트의 스토리지는 최대 2 64의 값을 허용하며 11 자리 이상을 수용합니다. 항목이 그렇게 많으면 어쨌든 서버급 데이터베이스를 원할 것입니다. 정말로 숫자로 생각하고 싶다면 numeric유형도 제공됩니다.


도움이되는 몇 가지 의견 :

첫째-쓰기 중에 전체 데이터베이스를 잠그고 ( http://www.sqlite.org/faq.html#q6 ) SQLite를 사용하지 마십시오 . .Net 응용 프로그램에서는 스레드로부터 안전하지 않습니다. 스레드를 지원하려면 다시 컴파일해야합니다 ( 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 )

이것이 조금 도움이되기를 바랍니다 ....


다음 두 가지 요소에 착수해야했습니다.

  1. 저는 Sql Compact를 많이 사용하며 단일 파일 데이터 저장소가있는 단일 사용자, 임베디드, 데이터베이스에 대해 작동합니다. 모든 SQL 장점과 트랜잭션이 있습니다. 그것은 나에게 충분히 평 행성을 가지고 있었다. 이 페이지의 반대자 중 일부는 제품을 정기적으로 사용합니다. 서버에서 사용하지 마십시오. 제 고객 중 상당수는 파일이 "데이터베이스"라는 사실조차 모르고 있습니다. 이는 구현 문제 일뿐입니다.
  2. 아마도 사용자의 데이터를 암호화하여 프로그램에서만 볼 수 있도록하고 싶습니다. 이것은 단순히 일어나지 않을 것입니다. 프로그램이 데이터를 해독 할 수있는 경우 키를 어딘가에 저장해야하며 충분한 전담 공격자가이를 찾을 수 있습니다.

키를 복구하려는 노력이 정보의 가치에 미치지 못할만큼 충분히 키를 숨길 수 있습니다. Windows에는 몇 가지 깔끔한 컴퓨터 및 사용자 로컬 암호화 루틴이 있습니다. 그러나 디자인에 사용자가 컴퓨터에서 숨긴 데이터를 찾을 수 없다는 강력한 요구 사항이있는 경우 (하지만 프로그램은 그렇게 될 것입니다) 다시 디자인해야합니다. 이러한 보증은 단순히 달성 할 수 없습니다.


SQL CE는 저에게 수수께끼입니다. 또 다른 SQL 데이터베이스 플랫폼이 정말로 필요 했습니까? 그리고 그것은 MS의 모바일 플랫폼을 겨냥한 지난 몇 년 동안 세 번째입니다. 그것이 마지막이 될 것이라는 확신이 많지 않을 것입니다. SQL Server와 기술을 많이 공유하지 않습니다. 내가 말할 수있는 한 처음부터 새로운 기술입니다.

나는 그것을 시도한 다음 SQLite와 Codebase 모두에서 더 성공적이었습니다.

편집 : 다음은 (많은) 차이점 목록 입니다.


ntext매우 큰 텍스트 데이터를 지원합니다 ( MSDN 참조 -이것은 Compact 4.0 용이지만 언급 한 데이터 유형의 경우 3.5에도 동일하게 적용됩니다).

int은 숫자 데이터 유형이므로의 크기는 44 바이트 / 32 비트 스토리지 (–2,147,483,648 ~ 2,147,483,647)를 의미합니다. 11 바이트의 데이터를 단일 열에 저장하려면 varbinary크기가 11 인 유형을 사용하십시오 .

SQL Server 세계의 자동 증가 열은 IDENTITY키워드를 사용하여 수행됩니다 . 이로 인해 행에 데이터를 삽입 할 때 SQL Server에서 열 값을 자동으로 결정하여 다른 행과의 충돌을 방지합니다.

사용자가 애플리케이션에 직접 액세스하지 못하도록 SQL Compact에서 생성 할 때 암호를 설정하거나 데이터베이스를 암호화 할 수도 있습니다. MSDN의 데이터베이스 보안을 참조하십시오 .

위에서 언급 한 모든 항목은 실제로 제한 사항이 아니므로 SQL Server 사용 방법을 이해하고 있습니다.

Having said that, there are some limitations to SQL Compact.

  • No support for NVARCHAR(MAX)
    • NTEXT works just fine for this
  • No support for VIEWs or PROCEDUREs
    • This is what I see as the primary limitation

I've used the various SQL Server Compact editions on a few occasions, but only ever as data capture repositories on mobile platforms - where it works well for syncing with a server database, and with that sort of scenario is undoubtedly the optional choice.

However if you need something to do more than that and act as a primary database to your application then I'd suggest SQLLite is probably the better option, it's completely solid, widely supported and found in all sorts of places (used on the iPhone for example) but is surprisingly capable (The Virtual Reality simulator OpenSim uses it as it's default database) and there are lots of others (including Microsoft).


I must also chime in here with VistaDB as an alternative to SQL CE.

VistaDB does support encryption (Blowfish), it also supports TEXT as well as NTEXT (including FTS indexes on them).

And yes the post above is correct in that you have to look at the SQL Server types to really match them up, VistaDB also uses the SQL Server types (we actually support more than SQL CE does; only missing XML).

To see other comparisons between VistaDB and SQL CE visit the comparison page. Also see the SO thread on Advantages of VistaDB for more information.

(Full disclosure - I am the owner of VistaDB so I may be biased)


According to this post (http://www.nelsonpires.com/web-development/microsoft-webmatrix-the-dawn-of-a-new-era/) it says that because it uses a database file, only one process can access it for every read/write and as a result it needs exclusive access to the file, also it is limited to 256 connections and the whole file will most likely have to be loaded in memory. So SQL server compact might not be good for your site when it grows.


There are constraints... Joel seems to have addressed the details. SQL CE is really geared for mobile development. Most of the "embedded" database solutions have similar constraints. Check out

ReferenceURL : https://stackoverflow.com/questions/407521/what-are-the-limitations-to-sql-server-compact-or-how-does-one-choose-a-data

반응형