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 ?
Related
I have a website that uses 2 different DMS (MSSQL Server and MySQL). There is a table name product in both databases, these 2 tables have the same product ID.
In MSSQL Server: I stored price, quantity.
In MySQL: I stored name, size,...
Now, every time I query products, I would do like this:
- Connect to MySQL -> query products by a loop -> inside every loop, I will connect to MSSQL Server to get other data of this product.
I know this is totally a bad way, so I'm finding a new way to get what I want since I think my website is slower because of that kind of query.
Can you help me by writing pseudo-code or explanation, thank you.
You are right! Having your website data in 2 different database technologies is not optimal.
Until you fix that, one workaround could be (assuming we are not talking millions of records):
User selects product A or Product category X on the website.
Get all data for product A or products of category X from SQL Server and store it in memory (for eg. in a c# dataset or python data frame)
Get all data for product A or products of category X from MySQL and store it in memory (for eg. in a c# dataset or python data frame)
Join the 2 in memory objects based on Product Id
Use this combined dataset for display your website
If required, Update (commit) data to the databases at the end of the session (will need to consider how to deal with dirty read scenarios)
I would like to ask because this makes me bald since last week.
I have to make a complaint form for stores for our products.
We have some contractors and they have their own stores/resellers.
Each reseller has own link to the same form with just a list of stores related to only one contractor.
Already I have multiple tables (as many as I have contractors) with stores inside each.
I wanted to upgrade script with some features and decided to rebuild database.
But have a question - better is to have one table with all stores from all contractors or to have multiple tables for each contractor separately? What is the safest option.
I know that if database will be compromised - all tables will be visible, so all in all there is no difference.
Just thinking - based on your better than mine experience:
- better is to switch "tablename" in MySQL connection related to URL (like I already have)
or
- better is to have one "tablename" with i.e. "contractor" column to select only stores related to contractor?
I will be thankful for your opinion and explanations (if you can) - what and why is the best.
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
I am developing an app in cakephp with user auth. Users will add their customer names every time they get orders. So I want to have an auto complete textfield for customer name to add orders. Each user will have their own set of customer names.
So should i create a big text to store customer names(all terms with comma seperated)
/ or /
varchar for each term (1 term in 1 record)?
I will use foreign key to separate users customers.
I am planning to use jQuery ui auto complete with sourcing terms from the customer table values.
My big concern is database capacity, I would like to save the space in database because I have other tables and a lot of users too.
(I do not have a programming background, so please forgive me for my typo)
Thank you.
Use multiple records, one for each term. That is what databases are designed to store.
If you store all the terms in a comma separated list, you will discover that there are lots of things that you cannot easily do.
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.