I am trying to find best solution for this scenario and have researching but couldn't find a best way.
We are providing Service A to the clients, Service A has set of schema structure. Now we are in the process of building another/different application which will be Service B with separate schema structure. What is the best way that I can keep one consistent customer and their users in both schemas.
I have looked into FK relation with different database but it is not recommended
I am not sold on the replicating the table in the other database
Schema A: Customer table, user table, service A schema
Schema B: Customer table, user table, Service B Schema
Any recommendation or resources you can point me to?
Related
I have a table that stores different software services a company offers. The services are tagged by the Industry it serves, the LoB it belongs to, and the technology involved in the service. The service can have multiple tags on each of Industry,LOB, and Technology.
For eg: Following could be the master data:
And a transaction data could look like this :
I need to create a view that can be used to query data by Industry/LoB and Technology tags. For time being I've Left outer joined all tagtoService relation tables(service-technology, service-LoB, Service-Industry tables) to the services transaction table. but this goes for a huge number of records as it is possible to typically have one service tagged to up to 10-15 industries and technologies.
Just wanted to know what is the optimal way to model this data so that I have provision to query for service by all of the three tags right from within one view.
I am not a Data modeling expert and this is more of my first venture into the data modeling side- so please pardon the 'noob'ness of my question :). I use SAP HANA as the database and expose data via an OData service for which I want to use this view as a datasource.
If you're asking modeling the data: Normally in your transaction table, you keep the foreign keys, not the text columns that can be obtained via foreign keys from the master tables. I bet that's what you meant as well but the example shows text values in the transaction tables.
Other than that, I think what you have is sound and reasonable. These "tag" tables represent different level of granularity for the "services" table and it can be counterproductive if you combine them in a single table (examples: single column with comma separated tags, XML / JSON columns, multiple columns [LOBTag1, LOBTag2, ...] ) b/c that will make these columns non-indexable and/or hard to query. You may have optimization with XML and JSON columns but those are should not be considered unless the columns are too many and sparse.
Is there a way to create relationship between entity and database table in Moqui?
If no? Is there a way to create ViewEntity between entity and database table in Moqui and show data and search in it? If relation between tables exist in database how can I use these tables to show data and search in Moqui?
I'm trying to design my database with very basic tables and I am confused on the CORRECT way to do it.
I've attached a picture of the main info, and I'm not quite sure how to link them. Meaning what should be a foreign key, or should some of these tables include of LIST<> of the other tables.
UPDATE TO TABLES
As per your requirements, You are right about the associative table
Client can have multiple accounts And Accounts can have multiple clients
Then, Many (Client) to Many (Account)
So, Create an associate table to break the many to many relationship first. Then join it that way
Account can have only one Manager
Which means One(Manager) to Many(Accounts)
So, add an attribute called ManagerID in Accounts
Account can have many traedetail
Which means One(Accounts) to Many(TradeDetails)
So, add an attribute called AccountID in TradeDetails
Depends on whether you are looking to have a normalized database or some other type of design paradigm. I recommend doing some reading on the concepts of database normalization and referential integrity.
What I would do is make tables that have a 1 to 1 relationship such as account/manager into a single table (unless you can think of a really good reason not to). Add Clientid as a foreign key to Account. Add AccountID as a foreign key to TradeDetail. You are basically setting up everything as 1 to many relationships where the table that has 1 record for the id has the field as a primary key and the table that has many has it as a foreign key.
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'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.