New answers tagged database-design
0
Since the source of truth is a git repo, you could forgo using a database if you can just clone it to your web server. Then have your backend just read the local copy instead of requesting it from Github every time. This makes keeping the data in sync easier too, since you can just make a cron task that does a git pull every once in a while.
If you don't ...
1
Just keep it in memory
Even the full county level CSV data is relatively small (16 MByte) so it would be possible to fully cache it in backend memory without a database and keep a simplistic index on state and county in memory. The data could be held as copies of the lines of original CSV file, so your backend could deliver it with minimal effort in the ...
4
To allow a variety of queries on such data, which transfer only the requested amount of bits and bytes over the network, one needs to preprocess and optimize the data for this purpose, there is no way around this. That is exactly what databases are made for. Trying to make things simpler by "avoiding a database" will end up in building a database ...
5
The ability for a customer to add arbitrary fields is pretty common for certain kinds of internal enterprise applications. There are several options to implement functionality like this, your example is probably the more unusual option. A typical implementation is the Entity Attribute Value model, which is probably what you mean by addding rows instead of ...
0
Sounds cool. Just please one-way hash the passwords. People reuse passwords among services and a data leakage can harm everyone.
Or if you make users, funds and transactions separate tables, you'll be able to run queries such as
select user_id, trans_id form transactions
where date >= today - 10
and bank like "Lloyds"
So I vote for separate ...
2
How does it work?
Database atomicity (aka the A of ACID) is an appearance of atomicity. The general idea for an update is:
keep the old value where it is unchanged
as long as the transaction is not committed, continue to provide the old value to every other db session;
the operations belonging to the transaction, i.e the updated values, are written to a new ...
4
First things first, based on this question it appears you do not at all understand the concept of atomicity. I’d recommend doing a bit more work to understand that before moving on to distributed computing concepts.
Secondly, why in God’s name are you making a weird ID system? People have made perfectly fine, safe, practical ID systems for decades. Ones that ...
1
In the ERP I'm developing for, all tables have a surrogate and almost all tables have a natural key. As you can see from Christophe's and Ewan's answers, both types of keys have their pros and cons. So it makes some sense to have both, although this adds complexity. Relationships in this ERP are often done with the surrogate keys, but these keys are almost ...
7
Your current requirements do not take into consideration the effect of time: sooner or later, your company will modernize its catalogue or reorganize its organizational structures. Items will then have to be organized differently:
If you opted for a dumb sequential numbering, you don't care: you just change some attributes of the item. And there you go!
...
0
What you are comparing is natural keys vs surrogate keys.
Your natural key is productType = SEDAN a surrogate key might be productType = 7
My main problem with surrogate keys is that when humans start to use them they gain a pseudo meaning and become the natural key. Before long instead of saying, "show me a report of all the SEDANS we sold this year&...
3
The question is not so much how the world does it, but how you should do it.
The world is full of websites that are designed with a main language in mind, and that later implemented some extensions to add additional languages (your option 1). For your problem, it's a feasible workaround. But it looks clumsy if you want to create foreign content first: you'd ...
0
Without knowing more about your system, there several solutions that may or may not work for you.
Version information can be a simple integer, or a date/timestamp value. If a simple integer you can go back 1 transaction fairly easily if you know the version number of the transaction. A timestamp will make it slightly harder to go back exactly 1 version ...
Top 50 recent answers are included
