I am planning to use ASP.NET MVC2 implemented membership system to manage users. Database that uses application should have tables that are related with these users. Is it possible to use two different databases and make relationships (foreign keys) between them or I will have to merge these two databases into one?
Thanks,
Ile
It is NOT possible to put up relationships between databases. You CAN use triggers to ensure relational integrity.
Otherwise I would say: all in one database, put them into different schemata.
I would put membership/roles in a separate database. I don't think having foreign key constraints is that useful. Its better decoupling if you go through the membership API rather than join with the tables directly. The only thing in the membership database you might need to look up often is the username. If thats becomes a performance problem I'd probably just create an lookup table, either in memory or in a lookup table in the other component's database.
Related
PersistedGrants table has ClientId, SubjectId and Type columns as navchars. I would expect them to be foreign keys instead referencing to Clients, Subjects and Type tables. I've been wandering why this patter has been chosen? Is it performing better this way despite taking more space?
Also keeping all in one thread, how can I configure IdentityServer4 to delete expired rows(Keys)?
Thanks
I'm not the author but I'd imagine it's because the design of the framework is not wedded to having to use a relational DB. The repositories for configuration and operational data are separate and could live in physically separate databases and therefore enforcing referential integrity when you happen to be using the same DB for both doesn't really make sense.
I'm am currently developing one project of many to come which will be using its own database and also data from a central database.
Example:
the database "accountancy" with all accountancy package specific tables.
the database "personelladministration" with its specific tables
But we also use data which is general and will be used in all projects like "countries", "cities", ...
So we have put these tables in a separate database called "general"
We come from a db2 environment where we could create foreign keys between databases.
However, we are switching to MS SQL server where it is not possible to put foreign keys between databases.
I have seen that a workaround would be to use triggers, but I'm not convinced that is a clean solution.
Are we doing something wrong in our setup? Because it seems right to me to put tables with general data in a separate database instead of having a table "countries" in every database, that seams difficult to maintain and inefficiënt.
What could be a good approach to overcome this?
I would say that countries is not a terrible table to reproduce in multiple databases. I would rather duplicate static data like that than use more elaborate techniques. There is one physical schema per database in sql server and the schema can not be shared. That is why people use replication or triggers for shared data.
I can across this problem a while back. We have one database for authentication, however, those users have to be shared across multiple applications some of which have their own database.
Here is my question on this topic.
We resorted to replication and using an custom Authentication/Registration service agent to keep the data up to data.
Using views, in what Sourav_Agasti suggested in his answer, would be the most straight forward approach for static data. You can create views and indexed views and join data from databases on linked servers.
Create a loopback linked server and then create a view(if required, on each database) which accesses the table in this "central database" through this linked server. There will be a minor performance impact but it more than enough compensates by being very simiplistic.
I have shared resources across all of my databases. Users, Companies etc. These are shared between all of my databases and the tables are the same. I want to create on Database for these tables and have all of my databases reference this one instead of having multiple tables that are the same. I come from a C# background and I am not very proficient in SQL. I am writing a new application that uses several of the databases we have.
Question: Should I make one database an authoritative source on these resources? The problem I see is I need Foreign Key relationships between databases and without triggers this is not possible. Not to mention when I write my linq statements I cannot query by these items.
We were able to achieve this by having one central database as the source of truth, then having copies of the applicable tables moved out to all the databases that needed it via triggers. You have to make sure all CRUD is done to the source of truth database, otherwise it gets very complicated to manage everything. You can then create the foreign keys to the copy tables.
we are using .net mvc and sqlserver db.
EDIT
We are also using NHibernate for data access. I mention this because we will not be writing our own sql or do stored procs. triggers in the db might work but I don't know if you can do that between databases.
END EDIT
we want to have a multi tenant set up so each client has there own instance of the db. However, we need to have each tenant connect to an other database which has a great deal of user information. there will be some small amount of shared data between them. Basically the tenants will be referencing the data of the users in the shared database.
The idea is that some people will use just the shared database ( independent clients ) they then may well be hired by one of the tenant clients. the tenant will then want access to the new employees data in the shared database. Further the employee may leave one tenant and join another or leave one and remain independent and want access to thier data. We could of course have the shared database schema in each tenant and just do a big export import each time some one left or joined but this seems like a lot of trouble too.
I am asking for any advice on how to manage the fact that the tenants will have references to the shared database but no referential integrity. Or if there is an alternate approach or whatever.
Thank you,
Raif
Across databases you have to give up declarative referential integrity (foreign keys). However you can still enforce this (if you think you need to) using after or instead of triggers, or if you control all data manipulation via stored procedures, you can do it there (on insert or update, for example, you can check first, or as part of the modification join to or use EXISTS against the table(s) in other databases to be sure that a valid value is being used).
I've worked with multi-tenant models and there can be huge benefits that are worth the costs (e.g. giving up DRI in some cases). For things that are mostly reference data and that aren't free-text entry, there shouldn't be a whole lot of extra effort required.
I've been tasked with revisiting a database schema we designed and use internally for various ticketing and reporting systems. Currently there exists about 40 tables in one Oracle database schema supporting perhaps six webapps.
However, there's one unifying relationship amongst them all: a rooms table describing the room. Room name, purpose and other data are thrown into a shared table for each app. My initial idea was to pull each of these applications into a separate database, and perform joins between a given database and the room database. But I've discovered this solution prevents foreign key constraints in SQL Server 2005. It seems silly to duplicate one table for each app and keep those multiple copies synchronized.
Should I just leave everything in one large DB, or is there something else I can do separate the tables without losing FK constraints?
The only way to achieve built-in referential integrity is to have the table inside the database in which it is referenced. You might be able to achieve the equivalent of referential integrity using triggers but it would likely be deathly slow.
You might be able to use SQL Server replication, in it's "Transactional replication" mode/form. http://msdn.microsoft.com/en-us/library/ms151176.aspx
if all the apps truly use and depend on the rooms - then keep them all in one DB.
you can still set privilege on the tables properly, and manage the data sets in the non overlapping areas normally -
is there any task you imagine you will not be able to perform when things are together?