How does one implement a foreign key check in JSONSchema? I can see how to implement a check on keys. Do you have to ref another document and handle it that way?
It sounds like you're talking of JSON Schema being used in a database, like mongodb (which supports JSON Schema validation).
JSON Schema is only designed to validate indivudal "things".
It sounds like you want referencial integrity checks, in whcih case you need to look at the databases documentation for how to do this. You cannot do it with JSON Schema
Related
All,
In my product, we manage the user data in RDBMS (postgres). However, we got an requirement to make those data available over LDAP protocol.
I have explored the OpenLDAP's backend-sql option. However, I found there is an requirement that the primary key used to identify the user records should be of type Integer. However, In my product, we use GUID (instead of integer) as primary key.
So, I am wondering
1) Is there is a option to get OpenLDAP's backend-sql work using GUID as primary key.
(OR)
2) Any other opensource alternative to achieve my requirement.
Thanks
For instance, i have these entities
Client : table
TransactionA : table
TransactionB : table
..
TransactionZ : table
TransactionA to TransactionZ table is referenced to Client
in database structure, i've been thinking of creating new table TransactionA for every new Client registered and has a schema with the Client.Code so it looks like clientA.tbl_TransactionA.
with this structure, i think my database would generate thousands of table depending on how many clients will register which i think that it is hard in maintenance if there's a modification in core.
I would like to ask for your opinion on the best approach on this matter, advantage and disadvantage.
PS:
I am using Entity Framework (code first), MSSQL
Thanks in advance.
Creating a table per client would not be a good idea on many levels. To pick one of the more obvious ones, using Entity Framework you would have to alter and recompile your code each time you wanted to add a client. You'd probably have to use reflection or to figure out which client DbSet to reference when seeking a transaction.
It isn't clear what has driven you to this design consideration, but it would seem obvious that the more reasonable model would be to have a Transactions table that had a foreign key / navigation property to the Client table. I assume there's some good but unstated reason why this would not suffice, though.
I have a complex iPad app moving to use Core Data. I receive data from a server which has foreign keys built into the various tables to represent relationships between tables (entities).
As I rewrite the app to use Core Data, should I maintain the foreign key structure and create my own accessors, or convert them to Core Data relationships or use both? Seems double the work. I already have the data to link two tables that I potentially need to maintain for data I send back to the server. Yet Core Data will create its own keys for relationships. It duplicates information and could get out of sync.
I could:
1. Keep the existing attributes to represent relationships between tables and write my own fetches as needed.
2. Build an object graph as I receive the data from the server and use core data relationships .
3. Use a hybrid, sometimes foreign key attributes and sometimes relationships depending on need.
Is there a typically approach used for Core Data applications receiving most of their data from a server?
If you are going to use core data instead of sqllite, then convert to Core Data. Remember, CoreData is not just a relational database. It is used to persist an object graph. Thus, the way you lay our your data structures may be quite different.
Typically, you may have more de-normalized data in a Core Data application, but really, you should remap your data as you want it to be used in your application. Then you will know the real answer. However, I do not think I'd leave foreign keys... I'd use relationships because that's how core data will fit best.
I am deciding how I should create an entity which I pull from a 3rd party api. The concept of my entity requires two API calls, one of which pulls the unique data about the entity, and the other which gives me a full schema of all possible data that could belong to an entity.
I've already written a repository for the entity, but where does the schema map fit in the domain layer if I'm only going to grab it once?
How should the entity hold this schema data?
I'm not familar with the mapper pattern, but does that seem like this is the right use case for it?
If you have schema data and then data then you're dealing with an entity with dynamic properties, akin to a dictionary or hashtable, but with validation.
You could treat the schema data as an entity of its own, that provides the knowledge level to instantiate and validate entities, which lie on the operational level.
Take a look here (pdf) for many related patterns.
Is there a way to make a schema diagram from an SQL Server database using the stored procedures of this database?
I don't mind if I must use an external software.
You could try playing around with CodeSmith Generator. It's SchemaExplorer Schema Discovery API allows you to programmatically access database elements for a given database and do something creative with it. However, it will still be logically hard to reverse-engineer a schema/diagram this way.
You can build a SQLCLR procedure which uses the Scripter Class from the SMO library.
update: more info on the question reveals the idea is to generate a table schema with dependencies based on the content of the stored procedures.
The approach would be to generate the table structure from the information_schema views and then parse the contents of the syscomments table to figure out the relations. This will always be approximate as it is very hard to establish the one-to-many relationships purely from the SQL Statements. I think you can make a guess based on the field which is referenced more.
If you can't see the tables then you can not generate the schema.
That is, you can't if you have permissions on stored procedures only.
At least two reasons:
the stored proc may JOIN and use several tables
you can't see constraints, indexes, keys etc even if you had table names
Basically, you can only:
see what you have permissions on in SSMS etc
see the internals if you have VEIW DEFINITION rights
Edit, after clarification
There is no way to script implied aspects (such as missing foreign keys) of the schema from code