Making database software

For most flexibility and least amount of pain, create a single database at the main office with a table that holds the location id. Outages should be rare, beef up your connections if needed. If there's an outage tough shit for the branches.


Imagine how much hassle will be for reporting if there are multiple databases.

You'll have to do scheme updates on all the separate databases.

I'd have a table for warehouses (also branches if they can have multiple warehouses).

Products describe a product sold by the company.
Stock describes a product's quantity in a given warehouse.

>>59079409
I also guess this solution was the easiest and most logical

How would you solve travel time of physical goods from HQ to branch? Is it ok to make some "Travelling" table that stores all goods that are dispatched but not yet received by a branch? When they receive the goods it just goes from "Travelling" to "BranchX" table.

>>59079432
Yeah, that's the general idea, i am just thinking of some more delicate stuff.

>>59079462
Do you have lot level info on the products? If so you would create a lot table which contained a location id and you would just update the location id when it moved. You could either have a location id for in transit of a flag on the lot.

>>59079363
> How would you create database for company like this?
Deploy Cassandra. Or another distributed DB on top of Trove.

Use Apache Spark to work with it.

> c#, entity framework and sql server
Wrong choice for "cloud" stuff. But I guess there are some solutions involving SQL replication. Just not what I -or virtually any big company- would do at this point.

>>59079560
This is just a hobby project that went a little too complicated, i would really like to keep it c#,entity,sql server, because i plan to continue learning in .net framework.

Speaking of cloud, do you know some cheap sql server plans online? Azure seems to have a lot of options but i've read that normal options start from $20/month

>>59079363
> (i guess using barcode)
Generate Bar and QR code or something comparable, sure. You could also use RFID tags or whatever if that pleases you better.

>>59079554
I don't think lots are a must. My initial guess for this company was no lots, those lots would just add another layer of complexity (insert X,Y,Z goods into a lot, dispatch lot, when lot comes update goods X,Y,Z into a table).

I don't think i need lots for this specific project, even though it makes sense in real life

>>59079602
> i would really like to keep it c#,entity,sql server
I guess you might somewhat need to arrange it around the replication capability of a SQL server.

Or yea, have "fun" with Azure.

>Speaking of cloud, do you know some cheap sql server plans online? Azure seems to have a lot of options but i've read that normal options start from $20/month
Not much for the .NET exotic walled garden.

Almost all of the production clouds are on the JVM and other technologies, and so are the hosters:

https://alternativeto.net/software/microsoft-azure/
https://alternativeto.net/software/heroku/

The real cloud world is using Docker, Amazon S3, Spark, Openstack, ... (insert hundreds more things).

Virtually all of it cares not for .NET and Microsoft's plans to Embrace, Extend, Extinguish.

You're on the wrong track, sorry. Not that you can't use some of what you learned in the actual cloud world, but it's still a language switch.

File: IC145887.jpeg.gif (27KB, 338x658px) Image search: [Google]

27KB, 338x658px

>>59079698
PS: SQL replication is usually more or less unidirectional.

"Master" copy propagates down to "slaves". Everything not yet in the master is merely cached in a way, it usually isn't propagated to the other slaves and the whole thing is kinda "stuck" if the master (and maybe a failover master) fails - the slaves generally won't exchange their information directly.