Tag Info

New answers tagged

1

It mostly depends on the size of the data you return and whether the user is expected to use all the data at once. For instance, if it's a list containing hundreds of thousands of complex entries: The response served as a single JSON will be rather large, and: It is unlikely that the user will actually need to see all the data at once. Instead, the user ...


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 ...


0

Filtering should be done in the database. Databases are really good at filtering results using the WHERE clause. One should always govern that amount of data being queried, paged and returned. You don't want millions or rows going across the network and you don't want the database to page a result set that has a million rows as it is a lot of needless ...


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 ...


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 ...


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 ...


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 ...


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 ...


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 ...


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 ...


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 ...


0

One approach would be to design your database similar to how you would define a class hierarchy, where you define base table(s) (classes) that provide the common attributes, and then you add additional tables that provide specific attributes to extend the table to the specific products. Define a base product table create table Products_base as id ...


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 ...


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 ...


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 ...


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 ...


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 ...


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. ...


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 ...


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 ...


0

As noted by John F. Miller on another question at SO (http://stackoverflow.com/a/5373969/1793074), MongoDB is great at nesting data, but not so grat to search this nested data. Another great resource on this matter comes from the same answer: http://seanhess.github.io/2012/02/01/mongodb_relational.html Basically, you relinquish control when you work with ...


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 ...


0

Just because you're inside the same company doesn't mean you should expose everything to everyone. REST APIs are a way to define a limited consumer/provider relationship between teams in a company, with a clear contract. Amazon has been a pioneer in this form of organization. APIs also provide a layer of abstraction, allowing you to use a specific set 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 ...



Top 50 recent answers are included