We are implementing Services Oriented Architecture (SOA). We have different service databases for each, Customer Management, Orders, Shipping, Refunds. What is strategies to maintain foreign key relationships across tables in different databases (since cross database foreign keys are not allowed in SQL Server)? Should foreign keys be substituted with business API rules?
This is not Microservices; where database information is replicated in each arena, but SOA. We did not want put everything in 1 database, since different backup maintenance hours, did not want deadlock/runaway query to bring down all services. Service Oriented Architecture does not dictate if we should have 1 database or multiple.
You can use a Guid(UUID) as the key of your entities, generated by the creator and then you can use that Guid across databased and tables to reference the entity in question.
for example, when you create a new order, the ui will generate the order's Id, send a message to the component creating the order, the component will then publish an event using that orderId so that the other components can do related work to that order without accessing the database to get that id.
Make sense?
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.
When our IT department converts Access databases to SQL Server the relationships do not transfer over. In the past, I have provided ERDs that they can use to build the relationships. In this case, I didn't.
What are the possible consequences of defining the table relationships in the MS Access Front End versus on the SQL Server itself?
It would be ideal if I could just create the relationships in Access and avoid submitting a request to IT, but I don't want to risk performance issues now or in the future.
There may be some misconceptions.
A relationship in SQL Server enforces referential integrity (an order cannot have a customer ID that doesn't exist). It does not automatically create an index on the Foreign Key, so it has per se no impact on performance.
But in most cases it is a good idea to define an index on a foreign key, to improve performance.
A relationship that you define in Access on linked tables does neither. It cannot enforce referential integrity (that's the server's job).
It is merely a "hint" that the tables are related via the specified fields, e.g., so that the Query Builder can automatically join the tables if they are added to the query design. (copied from here)
So you should
Create the relationships in SQL Server to avoid inconsistent data. ("But my application logic prevents that!", I hear you say. Well, applications have bugs.)
Create indexes on foreign keys where appropriate to avoid performance problems.
If you are working with queries in the Access frontend, additionally define the relationships there.
Ideally you should have a test server where you can yourself define the relationships, and just send the finished SQL script to IT.
I am looking for a way to get a unique ID per database itself. The idea is to exchange objects between different installations of my application. Therefore I have unique IDs for all objects within a single database, but in order to exchange these objects to other databases with the same schema, I introduced a composite ID consisting of a primary and a secondary ID, where the primary is unique within a single database and the secondary should be unique across multiple databases with the same schema.
Does somebody knows a decentralized solution for this issue?
Using a global unique identifier for each row solves the problem. Java itself provides a UUID generator, but there are more (better) third-party generators as well.
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.
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?