New answers tagged database
2
Ultimately, it depends on your requirements, specificially
how often and for what reasons do you expect the application to lose the ability to reconnect?
is it reasonable to assume a reconnect will be possible some minutes later?
how much data can get lost in case there is unsaved data, and how important could that data be?
Depending on the answers to ...
2
What the user assumes the inputs - trial options - are […]
Don't allow the user to make such assumptions. With more that a handful of options, the user will guaranteed get some of them wrong.
Instead, let the user give each combination of options they want to use a descriptive name before starting a simulation. Then the user can recall that set of options ...
1
In the case of an SQL engine such as MySQL, the best option is to let the DB engine and its optimizer do the job: send the complex query and get the results.
There are several reasons for that:
SQL engines have in general an optimizer that is able to chose the best access strategy, taking into account dynamically the size of the tables, the existence ...
3
Your structure so far looks reasonable with a few caveats, so don't be too hard on yourself.
I wouldn't store any information about the components in the Products table directly if possible, so get rid of the part_list_id col. The product_id will give you the hook to build the component list later. This also means that you could add 'temporary' products to ...
2
Normally, for full historical tracking, you don't need the current status in a different table.
Instead, add two timestamps to your table which represent the start of the given time slice, and the end of the given timeslice. For an update, just set the end timestamp and insert a new row.
Something like this:
userid | status | validFrom | ...
0
While I aggree with Esben, that from a domain perspective the replies should be separate objects, you specifically ask about mongo, which is a totally different beast. For mongo, you should design your database not by looking at the storage of objects, but at the queries you make.
That being said, when you need to query a review together with its replies, ...
1
I can't reliably talk about all filesystems and all platforms. But I have some experience in dealing with file allocation reflecting disk/volume/partition/region structure.
The most obvious way is present in WinNT NTFS disks. (I'm not entirely sure about other win FSes). It can be easily done using userspace defragmentation API.
From my point you can not ...
2
You should store the replies as its own document because you can get scaling problems if storing with the review. This is an important part of DDD where it is called a consistency boundary.
I assume you want multiple users to be able to post a reply independently of each other. If you are storing them together you can risk some replies fail just because ...
0
If a message is posted by A saying that something has changed, B can consume that message and replicate a local copy of A's info and use that to do whatever B needs to do.
If you wanted B to be able to access A's internal data, you would be better of to just give it access to A's internal databases.
However you should not do that, the whole point of a ...
1
Think of Elasticsearch as an eventually inconsistent index on top of your DBMS. The index is built once for a specific state of the database, but when the content of the DB changes, one will have to update this index afterwards (for example, in regular intervals, or somehow coupled to these changes). Depending on how one implements the update strategy, there ...
1
Even if I'm late, I would to put my 2 cents on the argument because I think it's an important point when you want to evaluate e design an event-driven microservices architecture. Each microservice knows exactly which are the events that impact on its state and is able to wait for them. When the microservice is not avaliable, there should be a component that ...
1
You are looking at a schema compare tool. If you do a schema compare into an empty database, the diff should contain your database structure. Then, quickly commit the source files needed to create a new empty database to source control before any more partying happens directly on the live database without an option to roll back or version changes.
1
I think both Cristophe and Berin make good points about the considerations. I will not repeat these but offer some basic advice based on some personal experience with this.
If your database can support the LOBs you wish to store (they are within the limits for your platform) and your total space allocated to these LOBs is not a significant percentage of ...
3
I have the same argument, with different conclusions. The problem statement is that you have large text objects that need to be stored, but did not mention what actions need to be taken outside of storage.
Bottom line:
Blob storage is cheap, fast, and just about seven nines of uptime
Generally well secured, and you have good control over traffic can be ...
4
The law of the instrument tells us that:
If you have a hammer in your hand, every problem starts to look like a
nail.
So before jumping too quickly to a solution look objectively at the needs and requirements. In particular security
needs, access control, and transactional consistency requirements.
Blob in DB:
Pros:
benefits from the access ...
1
In a nondistributed database system, nondistributed transactions are to satisfy ACID.
Yes.
In a distributed data store, what are distributed transactions to satisfy?
ACID - but over a distributed system.
Example
You have a data message in a queue-system e.g. AMQP that you want to insert into multiple database tables. So there is two systems; queue-...
0
I am certain that I'll allow a maximum of five such properties in
addition to Id, Name, and Description. In addition, I can probably
restrict these to be strings. What's a good way to architect this?
If you know there are five, just have
CustomProp1
CustomProp2
CustomProp3...etc
And so forth. Also might want to have a table describing each property ...
1
I think you are looking for "BASE" (Basically Available, Soft state, Eventual consistency). BASE is usually regarded – or least proposed – as an acceptable alternative to ACID for distributed databases.
I like this explanation from ACID vs. BASE:
Basically Available: This constraint states that the system does guarantee the availability of the data as ...
0
If they are not included in the same deployment, the Database deployment package and the Code deployment package will get different version numbers and this will generate confusion trying to figure out which Database version corresponds to which code version.
This works fine if you have a single DB node, and a single application node.
However once you ...
Top 50 recent answers are included
