Tag Info

Hot answers tagged

27

SQLite offers a pretty good rundown of when to use it or not vs alternatives: https://www.sqlite.org/whentouse.html This summary line captures the SQLite use-case extremely well in my experience: SQLite does not compete with client/server databases. SQLite competes with fopen(). The article expands at length on this point. It also has a section ...


26

Even for a single system with a single user, a "real" database server makes sense: It uses a familiar language (SQL). SQLite does use SQL, but some embedded databases (e.g. object database, NoSQL) do not use SQL. Those tend to have a higher learning curve because they are less common. It provides referential integrity, constraints, triggers etc. that ...


19

I think it has to do with inertia. Amarok is based on XMMS which is from 1997. To have to have good database capabilities you had to use a server, because it was so much more powerful then the file based solutions, which by no means had good database capabilities. The upcoming and gaining popularity of good local embedded databases like SQLlite is ...


9

The most important discriminating feature is concurrency. If you have only one application that runs in one instance for the user, embedded solution (whether sqlite or some object storage) is usually OK. However if you have multiple instances that need to manipulate the database concurrently, you need to have a server to synchronize it. SQLite only allows ...


7

A bit about relational databases One of the most powerful features of relational databases is the ability to connect sets of data through common points. In order to do this efficiently, a database should follow the rules of normalization. To sum those rules up, a database should have: No repeating elements or groups of elements No partial dependencies on ...


4

Server side relational databases are great for being a normalised primary data store. However, in many cases: Persistent data storage isn't required because the data can easily be recalculated or retrieved again It adds too much latency to make a minimum ~50ms HTTP request every time you want to access the data Making frequent requests to data which is ...


4

Many of the other answers talk about concurrency as an advantage, but also since the db is running as a server, the database can run tasks without the need of the application running. This could be maintenance, backups, synchronization with another server or any of scheduled task. If you feel your app could turn into a client/server app, you may want to ...


3

If you allow a client to access the database directly - which they would do, even with a database abstraction layer, then: You get a coupling between their code and yours - particularly, there is a very strong coupling between your database structure and their code; Your client may do some pretty undesirable stuff on your database - whether it be updating ...


3

A typical "MVC for the web" program might look something like this: RDBMS <--> ORM <--> DAL/SL <--> Controller <--> ViewModel <--> View RDBMS - Your database, usually something like SQL Server, Oracle or Postgresql. ORM - An Object-Relational Mapper, like Hibernate. The ORM converts tables to class objects, and vice versa. ...


3

SQL concatenation applications like this benefit from a technique which I will call "1=1". I don't know Lua, so I'm going to use "pseudo-Lua." sql = "SELECT * FROM widgets WHERE 1=1 " if id != nil then sql += "AND id LIKE '"..id.."%'" if name != nil then sql += "AND name LIKE '"..name.."%'" If you still need the elseif exclusivity, the only ...


3

Do not make a table for every product. This problem has been solved many ways. Try this: Make a product (or products) table, put your common product attributes in the product table, then make an attribute table and a productattribute table, something like: attribute --------- attributeId attributeName attributeDescription productattribute ...


2

Specifically yes the name of the pattern in distributed systems is called eventual consistency. The common approach is to synchronously write the data to an event store and then write to SQL. Your queued background read job can rest assured that once the data is in the event store, it's a success and won't be lost. Usually people use a high-performance ...


2

There's nothing out there that will handle all of that. There's just way too much there. The closest you'll come is something like an MVC framework such as Ruby on Rails or Geddy. They provide your #1, #2, #3 (using Gems or npm packages, etc), and #4. For #5 it sounds like you mean HTTPS? If not can you elaborate? #6 depends. Do you mean the HTTP server ...


2

It depends on your data abstraction and overall application space, access management requirements, the investment you are planning on data maintenance, urgency of the required prototype, where you are in the learning curve, etc. If you would like to ensure a tightly integrated database to an application which does not require access from other ...


2

Unless you are running an embedded system with low memory and cpu, I don't think that running a server on the background is doing you any harm. Running a database server locally is fine. The database is meant to access and manipulate data. The network access is a plus, which may or may not be needed. There are some engineering and scientific tools that do ...


1

Since you are not developing a website or a web application, but a desktop application which stores its data on a server, there are indeed a few layers you can skip. A common approach, in this situation, is to use web services. When a service should be lightweight and interoperable (that is, you can use it with ease from virtually every programming ...


1

No. Every system has input, and in this case, the input will come from two sources: humans entering data, and machines providing statistics. "We are always concerned about accuracy," Ferrara said. "But for automation the only error potential, in general, is the result of data being entered incorrectly upstream in the process. And that would be by a ...


1

I do not think making decisions about if trial time was exhausted on client is a good idea. This can be easily fooled and can't be calculated with some precision. Since you have a web application, I guess, it would be much better to limit a number of API calls a trial user can make without payment. You can make some tests and map an average number of API ...


1

Should write and read parts be methods in a same class? I would disagree with this because reading and writing are two separate responsibilities and if you want to follow good practices such as Single Responsibility Principle, I would separate them out into two classes. It might seem like an overkill but you will see that with your code growing in the ...


1

Use XML if your data is a lot more nested and complicated than this. In this particular case I would suggest using JSON (if you cannot use relational databases as you have mentioned yourself). As for learning JSON it is very simple. There is nothing to it but learning the structure. Once you got the structure down you can pretty much create any type of ...


1

If I understand correctly what a DBAL is, then the answer is that a REST interface allows you to use any language for its clients, while a DBAL is a library that allows you to use a single language for its clients. This, in turn, can be an advantage for a company where there are many development teams and not all of them are proficient in the same language. ...


1

You are thinking that REST is for database queries and it is not. REST represents the state of something at the moment. Using REST changes or retrieves a representation but that is all. If that state becomes available by database, it doesn't matter and no one cares because HOW that representation comes to be is not part of REST and neither are database ...


1

Some options I would consider (not exclusive choices): use code that actually does an UPDATE when the record already exists. The user is updating the record so an UPDATE statement would match that better than manually deleting and re-insert which is fraught with danger and error-prone. use a temp table (with the same table structure) to store the ...



Only top voted, non community-wiki answers of a minimum length are eligible