I'd like to design a cloud business solution with 4 default tables, a user may add a custom field(Column?) or a add a custom object(Table?).
My first thought was to create a new database for each account but there's a limit to database number on a sql server instance,
2nd solution : for each account create a new schema by duplicating the 4 default tables for each schema.
3rd solution : create 4 unique tables with a discriminant column (ACCOUNT_ID), if a user wants a new field add a join table dedictated to that ACCOUNT_ID, if he wants a new object then create a new table.
What are your thoughts? Does any body know how existing cloud solutions store data? (for instance salesforce)
BTW, I don't want to create a VM for each account.
Thanks all for your suggestions, that helped me a lot especially the microsoft article suggested by John.
Since few architectural points are shared between accounts (the 4 default tables are just a suggestion for the user, I expect a full customization), I've opted for the schema per account design with no EAV pattern.
Related
I have a table of dentists and services. And I want it to be dynamic so I have added a "add services" function. but how can I normalize it if services are not defined yet? since I didn't add yet.
the solution I've made is that I created a new table which is specialty where it creates new column every time I added a new service. But I dont know if it's very improper to create a new column within the add services function itself. But that's the only way I think. Are there any ways to solve it?
Dynamic columns are not good at all!
Tables should be static to be reliable.
Use relation-tables instead.
Example
You have a dentists table. It has an id column as primary-key.
Create a services table. Of course it should have a primary-key. besides that, put a dentist_id column. This will contain the id of the dentist in the dentists table.
If you provide more information and code or database schema, we maybe able to help more.
EDIT
As ADyson mentioned, if it is possible that multiple dentists work on one service, do a many-to-many relation.
Example
You have a dentists table And a services table. They both have an id column as primary-key.
Create a r_dentist_service table. Of course it should have a primary-key. besides that, put a dentist_id column and a service_id column. These should contain the respective IDs. This table will relate dentists to services.
To keep this as short as possible I'm going to use and example.
So let's say I have a simple database that has the following tables:
company - ( "idcompany", "name", "createdOn" )
user - ( "iduser", "idcompany", "name", "dob", "createdOn" )
event - ( "idevent", "idcompany", "name", "description", "date", "createdOn" )
Many users can be linked to a single company as well as multiple events and many events can be linked to a single company. All companies, users and events have columns as show above in common. However, what if I wanted to give my customers the ability to add custom fields to both their users and their events for any unique extra information they wish to store. These extra fields would be on a company wide basis, not on a per record basis ( so a company adding a custom field to their users would add it to all of their users not just one specific user ). The custom fields also need to be sesrchable and have the ability to be reported on, ideally automatically with some sort of report wizard. Considering the database is expected to have lots of traffic as well as lots of custom fields, what is the best solution for this?
My current research and findings in possible solutions:
To have generic placeholder columns such as "custom1", "custom2" etc.
** This is not viable as there will eventually be too many custom columns and there will be too many NULL values stored in the database
To have 3x tables per current table. eg: user, user-custom-field, user-custom-field-value. The user table being the same. The user-custom-field table containing the information about the new field such as name, data type etc. And the user-custom-field-value table containing the value for the custom field
** This one is more of a contender if it were not for its complexity and table size implications. I think it will be impossible to avoid a user-custom-field table if I want to automatically report on these fields as I will have to store the information on how to report on these fields here. However, In order to pull almost any data you would have to do a million joins on the user-custom-field-value table as well as the fact that your now storing column data as rows which in a database expected to have a lot of traffic as well as a lot of custom fields would soon cause a problem.
Create a new user and event table for each new company that is added to the system removing the company id from within those tables and instead using it in the table name ( eg user56, 56 being the company id ). Then allowing the user to trigger DB commands that add the new custom columns to the tables giving them the power to decide if it has a default value or auto increments etc.
** Everytime I have seen this solution it has always instantly been shut down by people saying it would be unmanageable as you would eventually get thousands of tables. However nobody really explains what they mean by unmanageable. Firstly as far as my understanding goes, more tables is actually more efficient and produces faster search times as the tables are much smaller. Secondly, yes I understand that making any common table changes would be difficult but all you would have to do is run a script that changes all your tables for each company. Finally I actually see benefits using this method as it would seperate company data making it impossible for one to accidentally access another's data via a potential bug, plus it would potentially give the ability to back up and restore company data individually. If someone could elaborate on why this is perceived as a bad idea It would be appreciated.
Convert fully or partially to a NoSQL database.
** Honestly I have no experience with schemaless databases and don't really know how dynamic user defined fields on a per record basis would work ( although I know it's possible ). If someone could explain the implications of the switch or differences in queries and potential benefits that would be appreciated.
Create a JSON column in each table that requires extra fields. Then add the extra fields into that JSON object.
** The issue I have with this solution is that it is nearly impossible to filter data via the custom columns. You would not be able to report on these columns and until you have received and processed them you don't really know what is in them.
Finally if anyone has a solution not mentioned above or any thoughts or disagreements on any of my notes please tell me as this is all I have been able to find or figure out for myself.
A typical solution is to have a JSON (or XML) column that contains the user-defined fields. This would be an additional column in each table.
This is the most flexible. It allows:
New fields to be created at any time.
No modification to the existing table to do so.
Supports any reasonable type of field, including types not readily available in SQL (i.e. array).
On the downside,
There is no validation of the fields.
Some databases support JSON but do not support indexes on them.
JSON is not "known" to the database for things like foreign key constraints and table definitions.
I have designed an ERD of movies and tv series which is confidential. I can give you an overview of database.
It has more then 20 tables (more tables will be added later) and it is normalized. I have tables like Movie, Actors, Tv Seriers, Director, Producer etc. So these tables will contain most important information and also these tables are connected (by foreign keys and middle tables like MovieActor, MovieDirector etc).
So the scenario is like
1) The standard “starting” database should have Actors, Directors, Producers, Music Composers, Genres, Resolution Types… pre populated and pre defined by the Admin.
2) For every user creating his personal movie collection, he will be starting of his database with all the pre defined data, but if he wants to, he may add further data to his personal database. These changes will only be affecting his database and not the standard "starting" database (which was defined by Admin).
3) The Admin should have a separate view to add Actors, Directors, Producers… that will become part of the standard "starting" database. Any further changes done to this database will be available to the users as updates.
Suggested Solution
Question
The suggested solution is seems like I have to create new databases all the time for each user which seems not possible. My question is how can I manipulate the suggested solution so that my solution will be effective and possible. I would prefer to handle the situation by using database relations, not by separate storage.
You wouldn't create multiple databases, you would simply add an ownerId field to all relevant tables - admin would have ownerId = 0, indicating the row is part of the 'starting database' and new admin entries are instantly available to users.
In any output for a user where you want to display the starting data and their own, you would add WHERE (ownerId = 0 or ownerId = userId) to the appropriate query or if they need to see just their own, just ownerId = userId.
Presumably, they would be able to create relationships between their own data or 'starting' data and this approach should still work.
Foreign keys will still work but deleting will delete user data - basically you should only ever add to the starting data, not take away or you will run into problems.
Creating a database for a project and well i sort of understand the concept of database but i don't know where to start. I know for my database i need to have the following:
Brand of the phone, model, some feature like size, operating system and touch screen?
To make this more like a database i decided to add more information such as carrier. So am thinking to make a database i would need these tables:
Mobile: ID phone(Primary key), Brand, Model
Phone: Model, size, and touch screen availability
Carrier: service provider, phone Id
The question is would this be a efficient database or should i combine the mobile and phone table? If this isnt good then what's the best way to make an collection system of cellphones?
You seem to be on the right track.
I would even say to break up the brand and model into 2 different tables.
To learn more about this relationship read this article
Database Relationships
MobileDevice
IDDevice, IDBrand, IDModel, IDCarrier
MobileBrand
IDBrand, BrandName
MobileModel
IDModel, IDBrand, ModelName, Size, TouchScreenAvailability
Carrier
IDCarrier, serviceprovider
Steps of creating a database for new application
Identify all functional entity
Create separate tables for each of them
Note: While creating it please follow normalization rules
Once functional entity related table creation is done than based on there relationship create corresponding tables to represent relationship
After that create your application related transacional tables
For any of sensitive type of transaction create tracking/history table(s)
For all lookup/referring related object create corresponding lookup tables
Note: While creating database for an application please consider few points like
scalablity of that application
scope of that application
target users, there location, type of user
Hope it make sense to you in order to start creating database for your application
I am doing the BI reports for a group of 5 companies. Since the information is more or less the same for all the companies, I am consolidating all the data of the 5 companies in one DB, restructuring the important data, indexing the tables (I can not do that in the original DB because ERP restrictions) and creating the views with all the information required.
In the group, I have some corporate roles that would be benefit of having the data of the 5 companies in one view, nevertheless, I am not interested that an employee of company 1 see the information of company 2, neither in the other way. There is any way to grant permissions restricting the information to the rows that contain employee´s company name in a specific column?.
I know that I could replicate the view and filtering the information using the WHERE clause, but I really want to avoid this. Please help. Thanks!
What you are talking about is row level security. There is little to no support out of the product for this.
Here are a couple articles on design patterns that can be used.
http://sqlserverlst.codeplex.com/
http://msdn.microsoft.com/en-us/library/bb669076(v=vs.110).aspx
What is the goal of consolidating all the companies into one database?
Here are some ideas.
1 - Separate databases makes it easier to secure data; However, hard to aggregate data.
Also, duplication of all objects.
2 - Use schema's to separate the data. Security can be given out at the schema level.
This does have the same duplicate objects, less the database container, but a super user group can see all schema's and write aggregated reports.
I think schema's are under used by DBA's and developers.
3 - Code either stored procedures and/or duplicate views to ensure security. While tables are not duplicated, some code is.
Again there is no silver bullet for this problem.
However, this is a green field project and you can dictate which way you want to implement it.
As of SQL Server 2016 there is support specifically for this problem. The MSDN link in the accepted answer already forwards to the right article. I decided to post again though as the relevant answer changed.
You can now create security policies which implement row level permissions like this (code from MSDN; assuming per-user permissions and a column named UserName in your table):
CREATE SCHEMA Security
GO
CREATE FUNCTION Security.userAccessPredicate(#UserName sysname)
RETURNS TABLE
WITH SCHEMABINDING
AS
RETURN SELECT 1 AS accessResult
WHERE #UserName = SUSER_SNAME()
GO
CREATE SECURITY POLICY Security.userAccessPolicy
ADD FILTER PREDICATE Security.userAccessPredicate(UserName) ON dbo.MyTable,
ADD BLOCK PREDICATE Security.userAccessPredicate(UserName) ON dbo.MyTable
GO
Furthermore it's advisable to create stored procedures which check permission too for accessing the data as a second layer of security, as users might otherwise find out details about existing data they don't have access to i.e. by trying to violate constraints. For details see the MSDN article, which is exactly on this topic.
It points out workarounds for older versions of SQL Server too.
If you want to restrict view data using the where clause, the easiest way is to create a view and then assign permission to the user.
example:
CREATE VIEW emp AS SELECT Name, Bdate, Address FROM EMPLOYEE WHERE id=5;
GRANT SELECT ON emp TO user