I thought it might be useful to share the results of my database research to date.
The requirements are: Embedded version for desktop versions of our apps, even if they also connect to hosted database servers. The client side choice must be cross platform on OS X, Windows, Linux, so the embedded version must work on all three platforms. The server database choice must be cross platform on OS X, Windows, and Linux at least, and hopefully several flavors of Unix. The database must handle large blobs easily and fast. The communication between the database and the database driver over the internet must be able to be fully encrypted with no programming effort or special (non-db) server administration, VPN, or SSL certificate. The database must accept the most standard revTalk database commands, nothing specific to the database, except at the time of establishing the connection. The database must be affordable for all concerned. Sometimes solutions are for organizations that have large needs and can afford database licensing fees from Oracle and such, but many times the org is too small to afford this. It must also be affordable for the developer. The database must run on all current processors and operating systems including 64 bit versions. Databases under consideration: Oracle - to expensive for most customers MySQL - have experienced problems with MySQL handling large blobs well. Also, Sun bought MySQL and Oracle is buying Sun, so I feel uncertainty about the future of MySQL. OpenBase - excellent on all fronts, but no driver for rev. FrontBase - excellent on all fronts except the 64 bit requirement SQLite - excellent for the embedded side, but no multi-user version for server side PostgreSQL - according to the rev 4.0 user manual, there is only a rev postgre driver for windows. Valentina - appears to be an excellent choice for all but the embedded version for Linux The current serious consideration is Valentina for the server side and SQLite for the embedded side. Our apps are database agnostic, so using one db on the inside and another on the outside is a possibility. So, today, that is the plan. Of course if FrontBase posts Version 5 tomorrow, I'll have to reconsider? Below, please find the discussion with users on the list that has lead to our current position. Thanks for listening. I would be glad to hear any further discussion. -- Alex Adams hawkVision tools for solving Wicked Problems (a)2 Technology Partners, Inc. 831-726-8013 a...@a2tecnology.com www.a2technology.com www.promisstudio.com universalconnector.wordpress.com ------ Hi Alex, ------ >From all text before, I can say it looks you have two options for now ------ A) Postgre SQL ------ B) Valentina DB ------ Btw, Valentina is able to do: ------ A) automatic compression of BLOB fields using ZIP, x7 save of space ------ B) automatic compressions of network protocol. As far as I know, not mySQL, ------ not Postgre not do that. Of course if file is binary you can self compress ------ it using ZIP, and then store as is. But not always this is a way. ------ Best regards, ------ Ruslan Zasukhin ----- Hi Alex, ----- Hi Bill, ----- >> I have had problems with MySQL and large BLOBs. ----- > ----- > Why use large BLOBs, as opposed to keeping them external to the DB and ----- > storing merely a reference to same? ----- Reasons against this can be ----- A) possibly not stable solution ----- B) it needs hide files from easy look inside ----- C) additionally it needs encrypt files. ----- This was major reasons I have hear from Valentina DB developers. ----- -- ----- Best regards, ----- Ruslan Zasukhin ---- Bill, That is a very good question. There are several reasons. Most of them have to do with security. Some server installations are locked down so tight that getting permission to write to a directory on the server from an app that does not reside on the server is problematic, even within a server farm. Transferring a file over the internet securely requires a secure communication channel. SSL or VPN, etc. With a pure database implementation, the app just needs the address and logon for the database server. Nothing else. FrontBase and OpenBase provide proprietary secure communications between their drivers and the database itself. All traffic is encrypted. Easy and safe. No coding or special setup required. The same setup works for any platform. It's unbelievable how handy this is. There are other reasons, but it is Sunday night here and I think I'm done thinking. ---- -- ---- Alex Adams --- Alex, --- > I have had problems with MySQL and large BLOBs. --- Why use large BLOBs, as opposed to keeping them external to the DB and storing merely a reference to same? --- - Bill -- Alex- -- I've pretty much switched everything serious over to postgresql. -- -- -- -Mark Wieder -- mwie...@ahsoftware.net > From: Alex Adams <a...@a2technology.com> > Reply-To: How to use Revolution <use-revolution@lists.runrev.com> > Date: Sun, 29 Nov 2009 18:26:44 -0800 > To: <use-revolution@lists.runrev.com> > Subject: Who's using what dbs? > > I need to decide on a multi-user database for a family of rev apps to run > against. Developing in other technologies, I have experience with OpenBase, > FrontBase, MS SQL Server, and MySQL and a little Oracle. I don¹t want to > use SQL Server for a whole host of reasons. Oracle is too expensive for > most situations. I am not aware of a rev driver for OpenBase. I have had > problems with MySQL and large BLOBs. That leave FrontBase which I like and > works very well with very large blobs, but is not currently shipping in a 64 > bit version. Is anybody using FrontBase? I see that there is Valentina. I > need to store and interact with masses of information, but there are no > relationships setup in the database and there are no joins in the SQL > statements. Constraints and relationships are handled by the apps. I store > files in blobs. Any kind and size of file. > > To the apps, the database is a generic place to put information. This > allows the apps to be database agnostic. So they can use embedded SQLite > and hosted multiuser databases, just the same. > > Any feedback would be appreciated. Oh yeah. Cross platform is a must. > > Thanks, > -- > Alex Adams > > hawkVision tools for solving Wicked Problems > > (a)2 Technology Partners, Inc. > 831-726-8013 > a...@a2tecnology.com > www.a2technology.com > www.promisstudio.com > universalconnector.wordpress.com > > _______________________________________________ > use-revolution mailing list > use-revolution@lists.runrev.com > Please visit this url to subscribe, unsubscribe and manage your subscription > preferences: > http://lists.runrev.com/mailman/listinfo/use-revolution _______________________________________________ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution