How to link two databases in progress 4gl with foreign key relationship?
FOR EACH jeld-wen.customer :
FIND FIRST adm2.order WHERE adm2.order.custnum = jeld-wen.customer.custnum NO-LOCK NO-ERROR.
IF AVAIL adm2.order THEN
DISP jeld-wen.customer.custnum adm2.order.custnum adm2.order.ordernum.
END
Progress has no "foreign key" support like you might find in some SQL databases. Relationships are maintained by application code similar to what you have shown.
Rule #1 - Progress is not SQL.
I cannot see a question in here although I assume you would not get the expected result from the query you have run.
The best thing you could do is refer the Data Dictionary for indexes and table relations it would give you a clear idea about the design of the Database and how are they related. In there you would find the relationship quite similar to 'foreign key relationship' in SQL if there is any.
Example Pregress DB:
Member Table Event Table
> memberid eventid
> memberstatus memberid
> memberpayno eventstatus
If you consider above example, memberid would be the foreign key equivalent in SQL.
Related
The first thing I'd like to say is that I'm not a database expert.
I found something wrong that the structure of the batch table described in the following link.
https://docs.spring.io/spring-batch/docs/3.0.x/reference/html/metaDataSchema.html
batch table relationship
The BATCH_JOB_INSTANCE and BATCH_JOB_EXECUTION tables, /BATCH_JOB_EXECUTION and BATCH_STEP_EXECUTION tables have a non-identifying, one-to-many relationship that matches the content described in the below MySQL SQL link.
https://github.com/spring-projects/spring-batch/blob/main/spring-batch-core/src/main/resources/org/springframework/batch/core/schema-mysql.sql
But isn't it correct that the BATCH_JOB_EXECUTION and BATCH_JOB_EXECUTION_CONTEXT tables must have a one-to-one relationship? (BATCH_STEP_EXECUTION and BATCH_STEP_EXECUTION_CONTEXT too)
And I don't understand why BATCH_JOB_EXECUTION_PARAMS does not have primary key.
I humbly believe that this drawing must have been drawn by a professional
and that if many people saw this drawing and did not correct it, I would be wrong.
I created tables using schema-mysql.sql and get the picture drawing by other CASE tool,
It displays one-to-one relationship.
Is this wrong or am I?
isn't it correct that the BATCH_JOB_EXECUTION and BATCH_JOB_EXECUTION_CONTEXT tables must have a one-to-one relationship?
Each job execution has its own execution context, and an execution context belongs to a single job execution. So the relation should be one-to-one. The same is true for a step execution. The diagram should be updated. Please open an issue with a reference to this SO question and we will fix it.
And I don't understand why BATCH_JOB_EXECUTION_PARAMS does not have primary key.
This is because job parameters have no identity, they are value objects. Therefore, the table does not have a primary key, but you can add one if you want. This won't alter the internal behaviour of the framework. This is explained in the appendix here.
I have a case where I need to implement the softDelete feature of TypeORM. Somewhere in my entity(let's call it Lead), I have a column that maps to another entity(let's call it Customer) with OneToOne relation.
............
#OneToOne(type => Customer, {})
#JoinColumn()
customer: Customer;
..........
The problem here is since soft remove doesn't remove the record completely from the database, whenever I remove any record from the lead table I can't add another lead for the same customer because of the OneToOne relation.
When surfing through the internet, I got a few solutions for similar scenarios of unique constraints like using:
Partial indexes &
Virtual columns
But here I'm searching for some kind of TypeORM level solutions while mapping relations. What could be the best play around for this case?
One to One relationship in TypeORM creates a unique foreign key constraint by default. Though the row is soft-deleted from the Lead table, there will still be a unique value in the table. So, while inserting another lead for the same customer, TypeORM will throw us a unique constraint error.
The solution for this issue is to remove a foreign key constraint from the relationship. This will now allow us to insert data for the same customerId in the Lead table.
Now what we have to make sure of is:
before inserting value in the Lead table, check if there already exists another lead for that customerId that is not soft deleted.
We also have to ensure that before deleting any customer from the Customer table, their particular leads are soft-deleted from the Lead table.
P.S: In a way this solution is a hacky solution. But since soft delete doesn't consider the foreign key constraint references, this is the suitable way that I have found so far.
Is there a condition in which two database tables can have more than one relationship between them? I saw a data model diagram which has something like that.
Yes, when a primary key from one table is used as a foreign key in another for several times. For instance, you may have a table "people" and a table "books" where books table will have fields writer_id, editor_id (among others) all referencing the primary key from people table.
I'm trying to workout the best database design for the following :
1) I have two (or more) tables in the database. "Sports", "Teams", "Leagues", etc..
2) Each of these tables can have a one to many relationship with another table in this case "Feeds"
The idea being that various database entities can each have a list of associated "Feeds"
It seems wrong to me to have multiple foreign key columns on the "Feeds" table, one for each of the tables (Sport, League, etc..), so my question is how best to model this?
It's worth mentioning that each feed can only belong to one of the other tables. A feed can't be associated with a "Sport" and a "League"
I've considered the following :
1) Add an additional column to each of the "Sport" "League" etc.. tables with a GUID.
2) Add another column to the "Feeds" table also with a GUID and populate this with the GUID from my other table, then query on this.
This would allow me to have multiple tables referencing the same column of the "Feeds" table but is this any better than having multiple nullable foreign keys, one for each table?
It is not a bad idea to have a foreign key pointing to Feeds in several tables. Foreign keys can be used to handle the 1:n relation (one-to-many).
It seems wrong to me to have multiple foreign key columns on the
"Feeds" table, one for each of the tables (Sport, League, etc..), so
my question is how best to model this?
Why do you think it is not a good practice, what would be the downside of this design?
I am trying to use Entity Framework DB first to do quick prototyping of a reporting website for a huge db. The problem is one of the tables doesn't have a key. I got an 'Error 159: EntityType has no key defined'. If I add a key on the model designer, I got 'Error 3024: Must specify mapping for all key properties'. My question is whether there is a way to workaround this WITHOUT adding a key to the table. The table is not in our control.
Huge table which does not have a key? It would not be possible for you or for table owner to search for anything in this table without using full table scan. Also, it is basically impossible to use UPDATE by single row without having primary key.
You really have to either create synthetic key, or ask owner to do that. As a workaround, you might be able to find some existing column (or 2-3 columns) which is unique enough that it can be used as unique key. If it is unique but does not have actual index created, that would be still not good for performance - you should create such index.