I'm planning a database for an enterprise cloud service. The service will be two web applications, one Warehouse management system and one for Invoices.
Companies can signup and become a "user" of the service, then they can have their Inventory and Invoice system online.
Should I keep all users/companies in the same table or should I have one table/application per user? It would be much easier to maintain if all users/companies use the same database table, but I think it would be easier to implement the serial number on invoices if I use one table per user/company.
The Inventory/Warehouse will contain up to 5,000 items per user/company.
Each Invoice are required to have a serial number, starting from 1 for the first invoice. So an Auto-Increment-column would be a good idea, if I have one table per user/company. Or how should I solve it if I put all companies in the same table and use a company_id-column?
How should I design the database for such an application? I will use MySQL as DBMS.
starting from 1 for the first invoice: that's probably not a good idea. Potential customers probably had a life before they join your service.
how should I solve it if I put all companies in the same table: just calculate the MAX of InvoiceId FOR THAT CUSTOMER, then increment it.
Related
Let me say I have a billing program webapp which will serve all users to maintain Thier business.
Eg:
Receipt No, qty, AMT, owner.
Are 4 tupples.
Now when multiple people use same online software, we are identifying transaction of a organisation by owners name.
When he takes his organisation sales report it has filter rows by owner name condition.
So this is delaying the process.
If we make master slaves database
Then we need only 3 Receipt No, qty, AMT, tupples since we can identify organisation by database name.
Which will be more efficient for server to handle !
I also need all organisation reports too combined.
P.S: I am using mysql server for db and web2py platform.
I am building a Rest Api using node, MySQL and MongoDB, but i am confused with the database schema to go for as the business case is B2B and for each business(customer) there is like 10 tables for general ledger, products, transactions, clients, sales, purchase and many like these. and for accommodating 1 to N relationship in sales and purchase record i will use MongoDB to avoid making default MAX number of columns for products in the purchase/sale orders in SQL.
Considering my customers need a separate data backup option for their data and in near future i am also planning to integrate the relationships between the application customers.
So, which is the best option to go for. I have read this question and answers quite carefully, and would like to ask whether should I go for option number 2 ?
Also, I would like to ask whether I should separate my entire backend (DB +Server) for specific BUSINESS TYPES using hostname mapping to business specific azure WebApp ?
Okay, my partners and myself created these a while ago. We are going to be transferring this into SQL through Visual Basic soon, but I want to make sure everything is ready to go. Two major complaints that we were not able to fix was...
"By having Transaction and Product directly connected you are unable to allow multiple products on the same order (customer can't order both a latte and cappuccino on the same order)."
"Membership table: Not sure what the data in DiscountTypeTotal means - do you have multiple pieces of data in the same field? (then your table isn't on 1NF).
It looks like you need to allow each member to have multiple discounts - so you need another table to capture that."
How do we effectively correct these? How else would we connect Transaction with Products? I understand that the customer can only purchase one item per transactions, so would we have products and another table for multiple items? Allowing multiple customers to have discounts, I am lost. Any help would be appreciated.
I'm a bit of a newbie with databases and database design, but I'm hoping someone can point me in the right direction. I currently have 14 monthly loan extracts, each of which contain all accounts, their status, balance and customer contact info as-of month end. Not knowing what to do, I imported each of the monthly files into Access with each table acting more like a tab from an Excel workbook. Laugh away - I now know that's not how it's supposed to work.
I've done my homework and I understand how to split up part of my data into Customer and Account tables, but what do I do with the account balances? My thought is to create a Balances table, create a relationship to the Accounts table and create columns for each month. This seems logical, but is it the best way?
99% of my analysis involves trend reporting and other ad hoc tasks - tracking the total balances by product type over time given other criteria, such as credit score or age. My intended use is to create queries to select the data I need and connect to it via Get & Transform in Excel for final manipulation and report writing.
This also begs the question "how normalized should my new database be?" Each monthly extract is cumulative, so a good 75% of my data is redundant contact info already, but how normalized should I go?
Sorry for ranting,but if anyone has any experience in setting up their own historical database or could point me in a direction that will get me on track, I would appreciate it.
Best practice for transactional systems is close to what you expect:
1. Create a Customer table
2. Create an Account table
3. Create an Account Balance table
4. Create relationships from the Account to Customer, and from the Account Balance to the Account table.
You can create a column for each month, provided you have Year as part of the key of the Account Balance table. Even better would be to have the key for the Account Balance be Account ID and Date.
However, since you are performing analytics over the data, a de-normalized approach is not only acceptable -- it is preferable. So yes, you can (and perhaps should, based upon your use cases) put all the data into one big flat table and then compile your analytics.
I am a developer and have never worked on DB before (designing a DB). I am designing a database for an employee management system which is a Node.js + Express application using MySQL as its DB.
I already have the required tables, columns sorted out but there are still few unknowns I am dealing with. This is my plan so far and I need your input on it.
The end users using this application will be small - mid size companies. The companies won't be sharing the tables in the database. So if there is a table named EmployeeCases I plan to create a new EmployeeCases table for each existing company or a new one who signs up for this application. I am planning to name the table as EmployeeCases_989809890 , where "989809890" will be the company id (or customer id). So if we have 3-4 companies who signed up for us, then all the tables (at least the ones which a company uses) will be recreated and named as TableName_CompanyId. My questions, is this a good way to go? Is there a better way?
All the employee's data is held by the Employee table, including their login and password. Now each Employee table in DB will be named as Employee_CompanyId (as per my plan above). My question is, when an employee logs in, how will I know which Employee table to query to? Or should I remove the login from the Employee table and create a universal Users table where all the employees will be stored? The Users table will also have the CompanyId as one of its column and I will read the CompanyId from there which will be used to query other tables.
Any reference, website or blogs on this type of design will be appreciated.
Thanks.
I don't recommend this approach, I think you should either:
A) Put all the information in the same tables and have a companyId column to sort them out
OR
B) Have separate databases for each company and use the appropriate database using the code.
The thing is, with your approach, you'll have a hard time maintaining your application if you have multiple copies of the same table with different names. If you decide to add a column to one of the tables, for instance, you will have to write as many SQL scripts as you have table instances. You'll also have a bad time with all of your unique identifiers.
Here are some advantages/disadvantages of each design:
A) Put all the information in the same tables and have a compagnyId column to sort them out
Advantages:
Simplest
Allow usage of foreign key / constraints
Great for cross / client data extraction
Disadvantages:
Not portable (a client can't just leave with his/her data)
Can be perceived as less secure (I guess you can make the case both ways)
More likely to have huge tables
Does not scale very well
B) Have separate databases for each company and use the appropriate database using the code.
Advantages:
Portable
Can be perceived as more secure
Disadvantages:
Needs more discipline to keep track of all the databases
Needs a good segregation of what's part of your HUB (Your application that tracks which client access which database) and that's part of your client's database.
You need a login page by company (or have your clients specify the company in a field)
An example of an application that uses this "two-step login" is Slack, when you sign-in you first enter your team domain THEN your user credentials.
I think Google Apps for Work as the same approach. Also, I think most CRM I worked with has a separate database for their clients.
Lastly, I'd like to direct you to this other question on stackoverflow that links to an interesting example.
You shouldn't split your tables just because companies won't share their information. Instead, you should have a companyId column in each table and access to the relevant data for each query. This should be implemented in your backend