Generally, how to save application data?
In a binary file, or a database? In other words, which structure can I use?
If there is a database table, how can I select data from it?
For simple applications settings, use QSettings - it provides persistent platform-independent application settings.
For more complex data, you might want to have a look at QSqlDatabase, several databases are supported, including SQLite. To select data or, more generally, to make an SQL query, have a look at QSqlQuery.
Related
While SQLite is for relationnal database, how couchbase use it for NoSQL data queryable ?
Couchbase Lite can use different storage engines internally.
In the SQLite case, the main document body is stored as a blob. Most of the data in the tables actually has to do with tracking revisions, views, supporting sync (replication), and so on. (This is as of version 1.4.0.)
So, to answer what I think is the main point of your question, CBL isn't turning documents into tables the way you would if you were trying to store the data directly in SQLite.
These are, of course, implementation details you should not rely on. If you're interested in finding out more, you can look at the source (Couchbase is open source) and use standard SQLite tools to examine the database itself.
I am recently working with a relational database program that has been written in Excel VBA. Excel VBA was chosen as it is a default application on computers where I work and therefore everyone would be able to use the database.
As part of the database development the need has arisen to add some more tables which will only interact programmatically with the current database. In order to consider all my options I am contemplating separating this new data either as an SQLite or second excel file.
I keep changing my mind as to what would be the best route and would appreciate information from those who work with the programs.
The new database would need to perform normal database functions quickly and efficiently. Given this context what are the advantages/disadvantages of using SQLite compared with excel?
Excel is not a database! If you want to use the Office applications, use Access, it is designed for that.
If you want to use SQLite, bear in mind that there is no concurrency. So if PC1 writes to the database, and PC2 wants to do that too, the file is locked by PC1 and you will get an error on PC2.
My recommendation:
You can also install SQL Server Express, this is free, with a few terms (10 concurrent users & max 10GB db). And then store your data in your SQL server. Use Excel as an interface to collect data from the SQL Server in your Excel/VBA applications. This is a lot more scale-able then Access, let alone SQLite.
OR: If your organization doesn't allow installation of software or whatever reason, go for Access.
You can use SQLite if you have a single application on a single device. Think about mobile apps, they use SQLite for example. If you have two applications on a single device, the concurrency problem of SQLite comes around the corner. It is possible that both apps want to write at the same time, which will give you an error.
I need to access some data on my asp.net website. The data relates to around 50 loan providers.
I could simply build it into the web page at the moment, however I know that I will need to re-use it soon, so its probably better to make it more accessisble.
The data will probably only change once in a while, maybe once a month at most. I was looking at the best method of storing the data - database/xml file, and then how to persist that in my site (cache perhaps).
I have very little experience so would appreciate any advice.
It's hard to beat a database, and by placing it there, you could easily access it from anywhere you wanted to reuse it. Depending on how you get the updates and what DBMS you are using, you could use something like SSIS (for MS SQL Server) to automate updating the data.
ASP.NET also has a robust API for interacting with a database and using it as a datasource for many of it's UI structures.
Relational databases are tools for storing data when access to the data needs to be carefully controlled to ensure that it is atomic, consistent, isolated, and durable. (ACID). To accomplish this, databases include significant additional infrastructure overhead and processing logic. If you don't need this overhead why subject your system to it? There is a broad range of other data storage options at your disposal that might be more appropriate, but should at least be considered options in your decision process.
Using Asp.Net, you have access to several other options, including text files, custom configuration files (stored as Xml), custom Xml, and dotNet classes serialized to binary or Xml files. The fact that your data changes so infrequently may make one of these options more appropriate. Using one of these options also reduces system coupling. Functions dependent on this data are now no longer dependent on the existence of a functioning database.
I'd like to know the best architecture.
We have a web application running different domains. Each domain has its own MySQL database but the db structure is the same for all of them.
We have a web application for the visible part of the application.
We have a dataLogic project
We have a dataEntities project
We have a dataAccess that contains only the methods to connect to the data base.
Before we called stored procedures on a database. But we had to change it because the performance was bad. Also, the problem was that every change we made we had in a stored procedure we had to copy to every database.
We are thinking in using a WebService to retrieve the data. Every domain can call the web service with a connection string and connect its database to retrieve data. This way when we change a SQL query we only have to compile the webService and change it, we don't have to change versions on multiples domains.
Also, what do you think about the SQL queries? Since we don't want to keep using stored procedures, what is the best way to do it? Directly from code?
Thanks
T
If you have multiple Database servers you will have to make Structural changes from one DB to another one way or another. There are many tools to change Database structures. These tools will look for differences between Schema, and will either generate the SQL code for you, or do the changes by itself (it depends a lot in the tool, there are powerful ones and not so powerful ones). Please do take a look at Toad for MySql. Now, for the Data changes, you may want to replicate the data from one Database to another. This is done through Replication.
We are thinking in using a WebService to retrieve the data. Every
domain can call the web service with a connection string and connect
its database to retrieve data.
This sounds like a good idea and since you already have "dataAccess" and "dataLogic" projects, it should not be too hard to make the services.
Also, what do you think about the SQL queries? Since we don't want to
keep using stored procedures, what is the best way to do it? Directly
from code?
I don't think it is a good practice to have the SQL queries directly into your code, but it depends in a lot of things, so I would suggest Stored Procedure vs Hard-Coding the queries, or LinQ (Entity Framework 4.1).
Good luck with your project and I will take a look at this thread frequently to see what you end up doing.
Have fun!
Hanlet
Is it somehow possible to create a stored procedure when using SQLite?
SQLite has had to sacrifice other characteristics that some people find useful, such as high concurrency, fine-grained access control, a rich set of built-in functions, stored procedures, esoteric SQL language features, XML and/or Java extensions, tera- or peta-byte scalability, and so forth
Source : Appropriate Uses For SQLite
Answer: NO
Here's Why ... I think a key reason for having stored procs in a database is that you're executing SP code in the same process as the SQL engine. This makes sense for database engines designed to work as a network connected service but the imperative for SQLite is much less given that it runs as a DLL in your application process rather than in a separate SQL engine process. So it makes more sense to implement all your business logic including what would have been SP code in the host language.
You can however extend SQLite with your own user defined functions in the host language (PHP, Python, Perl, C#, Javascript, Ruby etc). You can then use these custom functions as part of any SQLite select/update/insert/delete. I've done this in C# using DevArt's SQLite to implement password hashing.
Chris Wolf made a prototype implementation of SQLite with stored procedures. You can find the details at his blog post: Adding Stored Procedures to SQLite
Yet, it is possible to fake it using a dedicated table, named for your fake-sp, with an AFTER INSERT trigger. The dedicated table rows contain the parameters for your fake sp, and if it needs to return results you can have a second (poss. temp) table (with name related to the fake-sp) to contain those results. It would require two queries: first to INSERT data into the fake-sp-trigger-table, and the second to SELECT from the fake-sp-results-table, which could be empty, or have a message-field if something went wrong.
No, but you can :
Write long multi-statement scripts
Create temporary one-row tables called e.g. Vars to hold variables
Create a View over a Recursive CTE to program arbitrary functions in pure SQL queries.
So you can do most things you would normally do with stored procs.
For how to program functions in a SQL View see https://www.cafe-encounter.net/p3300/pretending-that-sqlite-has-stored-procedures-and-functions.
Alternatively you can:
Compile short single-page C programs to program arbitrary functions
This is easier and less work than you might think!
A step-by-step guide is at https://www.cafe-encounter.net/p3244/installing-and-using-sqlite-extensions-on-macos-and-maybe-windows-linux-too . This does add some deployment work: you will have to deploy the additional dll/so/dylib files with your application.
I've come across this question myself. I think stored procedures are supported in PHP PDO, but that module is handling it and building normal SQL queries to send to SQLite. So, in PHP, possible to write stored procedures in your code, but no performance gain from using them.
Correct me if I'm wrong, please.