BlackFish SQL

Steve have puplished some more stuff about BlackFish on his block.

See this LINK of Original Message from Steve Shaughnessy

Simple deployment. 

There are single file deployment options for both the .NET and Java platforms.  If you use the windows version, there is only one .NET assembly you need to deploy.    This is particularly nice for ASP.NET applications.  No longer need to rent a database from your ISP.  On the Java platform there is a single jar file to deploy.  The license file also needs to be deployed, but this is small and it is “not” machine locked.  This makes it easy to do simple xcopy deployments.  On both platforms the delployment size of the binaries is about 1.3 megabytes.

Industry compliance.

SQL-92 compliant.  Local and remote ADO.NET providers.  Local and remote JDBC drivers.  DBX4 100% Object Pascal win32/.NET driver.

Performance.

Early on we would do benchmarks against other Java databases.  However we quickly found that we were orders of magnitude faster than them.  We also found that we had no problem competing with databases written in native code.  Invariably, every time we found ourselves being beat it had nothing to do with managed code vs native code.  We could always match or beat the competition with better algorithms.  I know native code can be made faster for simple code, but with the complexity of transactional, high concurrency database kernel, better algorithms are king.  We have not performed major tuning for a while, and I’m not going to claim it’s the fastest, but this database is fast.

In-process execution.

The local ADO.NET and JDBC “local” drivers execute in process for improved performance and ease of deployment.

Delphi, C#,  VB.NET, and Java stored procedures and triggers.

These are safer and more powerful languages to write database stored procedures and triggers in.  In addition to using mainstream languages, you can also use off the shelf IDEs, debuggers and profilers to develop your stored procedures and triggers.

Really cross platform. 

Blackfish SQL pretty much runs every where .NET and Java run. We also have built a compact framework assembly for Blackfish SQL for the compact framework as well.  We are not ready to release this now, but we know it can be done. 

Unicode.

This is the only way Blackfish ever knew to handle character data.  Dealing with character data is always simple.  No multi-byte, national character, etc issues.  You also don’t need to specify the length of a string for performance reasons.  String storage is transparently managed.  For collation we use the collation key support provided by the .NET and Java platforms.  Why reinvent the wheel? 

64 bit support.

We didn’t have to lift a finger for this support.  If the .NET virtual machine is 64 bit, you can have a 64 bit database cache.  The same for a 64 bit Java vm.  Same binary for both 32 and 64 bit platforms.

Security.

Databases can be password protected and there is SQL based security including support for oles.  The database file itself can be encrypted using the Two fish 128 bit Two Fish block cipher.  Don’t forget your password.  There is no back door.  Some security conscious companies and government agencies view 100% managed code solutions as more secure.

BDE.

We have mentioned in our roadmap that Blackfish SQL as a BDE replacement.  Today this is still a bit of work because it requires that you move away from the simple TTable/Query navigational data access model.  Going forward we will be looking at what we can do to support a navigational model to facilitate BDE application migration to Blackfish SQL.  The idea is to support native win32/64 client applications that can connect to a Blackfish SQL server using a navigational data access model (TTable).

Tooling.

Our Blackfish SQL tooling is very basic.  Leonel put a lot of work into adding ADO.NET, dbExpress 4 and query builder support into the DataExplorer in a relatively short period of time.  Our plan is to improve the capabilities and extensibility of DataExplorer going forward not just for Blackfish SQL, but also for Interbase and the rest of the databases we support as well.  In the mean time, Blackfish SQL has built-in “DB_ADMIN” stored procedures that allow applications to perform many common administrative tasks including database backup/copy/defragment/verify/encrypt/configuration, change password, metadata retrieval, active connections, lock manager state, and server side logging configuration.  The built-in DB_ADMIN stored process allows us to avoid polluting the name space of our standards based SQL dialect with Blackfish SQL specific extensions.