I am thinking about using SQLite
It is a self-contained, server less, zero-configuration, transactional SQL database engine and is open source.
Will I gain anything by using Blackfish instead of SQLight ?
Why not Firebird?
http://www.firebirdsql.org
http://www.firebirdfaq.org
"...Firebird is a relational database offering many ANSI SQL standard features that runs on Linux, Windows, and a variety of Unix platforms. Firebird offers excellent concurrency, high performance, and powerful language support for stored procedures and triggers. It has been used in production systems, under a variety of names, since 1981...."
Stick with FOSS (Free Open Source Software).
Both SQLite and Firebird are excellent choices. Both fill your requirements. Both are very reliable, zero-configuration and support transactions.
Without knowing enough about your intended use, Firebird would be my first choice because it makes possible to migrate to a Client Server deployment with close to zero effort and it has a very robust set of features. It is all about the options.
IMHO Blackfish is not a god choice - "Blackfish SQL runs on both the .NET framework and on the Java platform." - enough said.
Use SQLite.
Much smaller, less overhead, no licensing issues etc.
Laslty, only you can decide which one will do everything you need a db system to do. Which one has all of the features you need to support?
John
I will vote for Sqlite first, because it's compact, lite and fast, but depend on your application you may go with other choices like Firebird or PostgreSql.
for example Sqlite has limitation to one writer at the same time, it may not be problem for most of desktop applications that used by one user, but it will not scale for more uses in future.
you can go with FireBird embedded as solution which will be act like Sqlite, then move to firebird server when you need more users.
In other side BlackFish database, will force you to install .Net framework on your client's machines, which is something isn't good IMO, specially if you need to distribute your application on Internet, beside it will require license when it scale for more than developer edition.
Another thing to consider is how are you going to access your data. If you are using DBX4 for instance, it is very easy to change what database you are looking at. In which case I would suggest trying both (plus any others that people highly recommend you try). On the other hand if you are using the the Interbase or ADO data access components then your ability to change is somewhat more limited.
Related
We're working on a ASP.NET MVC 4 project with Oracle DB (11g). Customer has asked us to add ad-hoc reports (OLAP) to our system, so we're looking at possible options. User interface should be integrated into existing ASP.NET MVC web-site and data source should be Oracle DB. What is the best available options for such configuration?
I guess this is rather late (being well over a year after the post!) but I would strongly recommend the OLAP option that is embedded into the 11g database.
Oracle have wrapped it in all sorts of crud and provided some not very good client tools (e.g. the OLAP worksheet) but the underlying engine, based on a tool originally called Express, has an extremely good pedigree and remains one of the best on the market. Performance is great, it has an excellent and fully-featured language and costs a fraction of Oracle's own Hyperion offering.
Best of all, it is embedded in the Oracle database allowing (relatively) easy transfer of data from one to the other (although they are still surprisingly much at arm's length, given how long the technology has been owned by Oracle).
Having had relatively limited success with the client tools provided by Oracle, we have tended to go back to basics and define/populate objects manually in the OLAP cube - although most of our applications tend to involve modelling/forecasting so require write-back, which is a strength of Oracle OLAP, but not well supported by the client tools as Oracle would rather you used the more expensive Hyperion.
I am planning to create a library related desktop application using Delphi 5, for which there would be a single database kept at one place and this application would be installed at different places more over in different cities.
Here, my doubt is Using Delphi 5, is it possible for all the instances of this application which are installed at different cities could access one centralized database? If yes then how?
If anybody is having any other ideas kindly feel free to share it. Because I have familiar to only desktop application development, that is the reason I am asking how these different instances of an application could access only one centralized database ?
So, all the screens and coding would be done using Delphi 5, moreover it would be a desktop application only the difference would be database access would be from different places.
That depends upon back-end database technology. By "desktop application development" u probably mean ISAM databases like Paradox, DBF-family, etc.
If so, then you should quickly learn about SQL, its concepts, ACID principles, etc.
I believe there is a lot of good books in English about SQL in general and SQL with Delphi link in particular. For staring u may try something like http://www.firebirdsql.org/en/books/, but basically you would have to cover three areas:
SQL in general, principles, patterns, etc
Details about Delphi wrt SQL designs.
Details about chosen database server, including components to connect it to Delphi, bugs, gotchas, etc
I think you'd hardly find all that in one book and would have to get two or three.
Then you would have make a network connection between clients and server.
That splits to two questions.
How to find server
How to connect to it
VPN are reliable solution, you may try Windows built-in methods, or simplier methods like TeamViewer, Comodo, Hamachi, etc
But that can make you whole server computer exposed to your clients.
You'd better find not whole-featured network, but a tunnel that would connect clients for database server and nothing else. In russian comunity classic solution to Firebird/Interbase family is http://sf.net/projects/zebedee for Windows. For Linux SSH is usually used.
You probably can find a lot of FAQ in English if you google for "tunneling" and you database server of Choice.
I need to take a huge Delphi XE application (backed by proprietary SQL server NexusDB) and begin providing my clients the ability to access the system in new ways:
Thinner Windows client for slow/VPN connections
Mobile/Tablet
Web
DataSnap appropriate for this or is introducing a middle tier the wrong way about providing remote/mobile access? Other solutions/ideas welcome.
(I have XE2 Enterprise but am stuck on XE Enterprise for awhile.)
DataSnap is being aggressively positioned by Embarcadero as a Multi-platform connectivity solution, where servers are written in Delphi, and mobile connectors are available (in XE2 and later) for a variety of mobile device platforms. So the quick answer is yes, it is suitable in general.
Is it suitable for you? You haven't said much that would help me answer that question; You are willing to buy Enterprise or Architect SKUs of Delphi, so I would guess yes.
If it was me, I'd look for a solution that implements a pure simple REST architecture that is available to every system out there, mobile or otherwise, no matter what language or platform, but I haven't got a suggested alternative because it seems to me that SOAP is nearly dead and that there is no universal replacement technology out there that does everything that soap client/server systems do. I'd be tempted to consider "roll your own REST+json" or evaluate Remobject's product offerings too, and select a path that makes sense for you, from a business and technical point of view.
Datasnap is fine, but it's not the only option. It's probably the simplest and most easy to roll out option currently available, and the only one "out of box" ready to go in XE2 if you want apple, android, and a few others, right away.
That depends on your security needs, and the way you're providing data to clients. As I often pointed out, dbExpress-Datasnap has big security flaws (while the DCOM version is not well suited outside a LAN, and does not offer out of the box mobile devices support).
A web application would have less issues because the datasnap-web server connection would be probaby internal, it would be up to the web application to ensure data protection.
What is the best way to write a client-server application under delphi? I know there's a DataSnap technology, but it's not in Professional version. Do You have any experience that You can share?
This is fairly wide open question, as it can depend on your database decision.
DataSnap really allows for N-Tier solutions, if your looking for Client Server you have
most everything you need in the professional version depending on the Database Choice.
For Client Server:
Client Server Architecture is when the Client communicates directly with the server.
There are several frameworks available they all follow the same pattern.
DB Connection -> Query -> (Optional Provider -> TClientDataset) -> TDataSource -> Visual Control
DBX
TSqlConnection - Connects to the Database
TSqlQuery - Query against DB producing uni-directional Dataset
TSqlStoredProc - Executes Stores Procedures against DB
ADO
TAdoConnection - Connects to Database
TAdoQuery - Query against DB producing Bi-Directional Dataset
Common Components
TClientDataSet - In Memory dataset that is bi-directional
TDatasetProvider - Takes other datasets and ties the data to TClientDataset
TDataSource - Ties a Dataset to a data-aware visual control
There are several other options available depending on Database Choice.
However, you seem to be asking about N-Tier (Middle-Tier) type solutions
For N-Tier
N-Tier architecture is when the Client communicates with Middle Tier that then communicates with the Server. It's referred to N-Tier as you have option to have multiple Middle Tiers or Application Servers.
Commercial Options (Required additional $$ to be spent)
DataSnap
DataAbstract
RemObjects SDK (Part of DataAbstract but can be used by itself)
KBMMw
Midware
I personally don't know of any free or open source options, although I suspect some exist.
Two options:
DIY (Do It Yourself). Write a communications layer and protocol yourself using Indy and/or ICS internet components. A lot of hard work and needs a lot of testing to get right.
Use a ready made framework such as kbmMW: http://components4developers.com/ or RemObjects: http://www.remobjects.com/ Both are not free but well worth the money you pay even if only measured by the development time/costs that you spare.
You can use
WST is a free and open source toolkit for web services consumption and creation with support for SOAP and XmlRPC and JsonRPC (the JsonRPC support is available only for FPC). It is compatible with Delphi. Better check out from svn as the 0.5 release is actualy outdated.
With Delphi Professional it is possible to write simple (no WS-* standards, no Soap 1.2 servers) SOAP client and server applications.
In many cases, Soap offers advantages regarding cross-platform / cross-language integration, standardization, design-by-contract and mature implementation guidelines, best practices and patterns.
For Soap there are great (and free) tools like SoapUI and IDE editors for Web Service Description Language (WSDL) documents like NetBeans.
Take a look at our Open Source Client/Server ORM.
It's multi-tier compatible, and you can have ORM at both Client and Server level.
ORM is used everywhere, and JSON is the format chosen for the Client/Server transmission.
You can start your application as local application, then just by changing the class type used to access to the data, it will become a Client/Server application communicating via Named Pipes, HTTP/1.1 or GDI messages.
It was designed to work with SQLite3 as a small but efficient database engine on the server side, but you can use the ORM without SQlite3. There is a pure Delphi in-memory engine provided, if you prefer.
This framework try to implement N-Tier architecture from the bottom up.
The upcoming 1.13 version will have a powerful filtering and validation mechanism, perfect for N-Tier architecture. There is some User-Interface units, with full reporting (and pdf generation), able to create most of the User Interface from code, using the ORM layout of the data.
It's based on the RESTful paradigm to access the data from the Client, via JSON. And there is a easy way of implementing Client/Server Services if the RESTful approach is not enough, just like DataSnap.
It's Unicode ready (uses UTF-8 at all internal level), and works with every version of the IDE, from Delphi 6 up to XE (even the Starter edition).
Since a few months ago I stopped to implement new projects with this kind of architecture (n-tiers, 2-tiers) Based on Delphis and specific DB technologies. I believe these architecture are not future prof. The architecture i'm using now is a 2-pier one. The server is a normal HTTP server. It works as app server* and optionally provides a web client. Developing clients in Delphi it's harder but worth it. Since specif tools are not available as the ones offered for DB connections, I use indy to send and receive data from the HTTP server. I do a GET request to fetch data and then parse it to show it on the GUI. Then a POST request to update or insert new data. The HTTP server handle all business logic :-)
Apart of being future prof, this architecture is cheaper and platform independent. And if you analyze it, this is the same architecture used by most mobile apps. So, if you plan to write a mobile client in the future, consider developing the app server with script languages (Python, PHP, Ruby, etc.).
That's my recommendation. Don't forget: Great things require great commitments!
An App Server is a service which provides your application (thin client) with with an interface to get and send data. Also it control the business logic. Your application don't care about DB's or controlling record relations and data constrains. That's all is transparently done by the app server.
For general-purpose client-server communication you can use our lightweight MsgConnect product. This is a cross-platform MOM (message-oriented-middleware).
I need to deploy a Delphi app in an environment that needs centralized data and file storage system (for document imaging) but has multiple branch offices with relatively poor inter connectivity. I believe a 3 tier database application is the best way to go so I can provide a rich desktop experience with relatively light-weight data transfer needs. So far I have looked briefly at Delphi Datasnap, kbmMW and Remobjects SDK. It seems that kbmMW and Remobjects SDK use the least bandwidth. Does anyone have any experience in deploying any of these technologies in a challenging environments with a significant number of users (I need to support 700+)? Thanks!
Depends if you are tied to remote datasets. If you aren't dataset bound then SOAP would likely be a good choice. Or, what I've done is write my own protocol that is similar to SOAP in nature. This was done before SOAP was standard and I'm glad I did - this gives you the ability to control more of the flow of data. It's given that if you have poor connectivity then you will be spending time supporting it. It's very nice if it's your own code you are supporting versus having to wait on a vendor. (Although KBM and REM are known to be pretty good vendors.)
Personal note: 700 users in a document imaging application over poor connectivity sounds like a mess. Spend the money on upgrading connectivity as it'll be cheaper in the long run.
Both kbmMW and RO SDK offer binary format, which is more compact than SOAP format,specially you are working with documents.
RO sdk seems to offer more GUI tools to help you doing your services.
Also give a RealThinClient SDK a look, it's a lightweight remoting framework.
But what ever framework you go with, your design of work will make it fast or slow, I have some applications working on slow 128kb lines, and it's working perfect without any user complain, but I don't do a large transfer for files.
One thing to remember...its not the number of users, but the number of them using the resources at the same time that will be the issue. Attempt to develop your application "server stateless" if at all possible, this will allow greater flexibility in the long term if you find you have to add more servers to the pool to support your customer base. The hardest thing about n-tier is scaling beyond the first server...plan on that from the start. Each request should not know anything about a prior request...or at the very least the request should have a way of passing the context so the server can look it up in a session table or something.
Personally, I would recommend RemObjects. I have used it with good results.
I don't know if it's the very best / most efficient (glad you asked this question!), but I've had good results w/RemObjects SDK + DataAbstract. The latter made much of the plumbing details less involved, which was helpful. Still implementing, but so far so good.
If you really wanna go "low-bandwidth" use BSD Sockets API - that'll give you full control over what's being sent and there you can send as little information as you want. Of course then you'll have to implement all the tiers yourself, but hey - that's still an option :D