#data-model — Public Fediverse posts on home.social

Neil Chandler's DB Blog @[email protected] · 2026-08-23 · 23:14 UTC

“Status” columns in Oracle

I wrote this blog post a while ago, and I’ve just spotted it in the backlog drafts, so I though it might be time to publish it. This may be old news to many of you, but I sometimes work on systems where consideration for how to store STATUS columns (or more accurately, columns with low cardinality / few values) at the design stage would have saved an awful lot of problems.

In the scenario where you are recording the status of an action within an Oracle table, there are many ways to accomplish it. However, some ways are better than others.

Let us say that we have 2 statuses; “NOT YET PROCESSED” and “COMPLETE”.

Let us also assume a 1,000,000,000 rows table for sizing purposes, with 1,000 rows “NOT YET PROCESSED” and all of the rest set to “COMPLETE”.

We could store and index these in several different ways:

Storing a descriptive status

 CREATE TABLE STATUS_TAB  (prim_key NUMBER,   otherdata VARCHAR2, etc...   STATUS VARCHAR2(20) NOT NULL );

We could store the values as they are represented above. Very descriptive, but it will waste a lot of space.
Storing the word “COMPLETE” one billion times will take about 7.5 GB.

There’s also no guarantee that you will have good data integrity – the data is not being validated against a STATUS_DESCRIPTION, so we should also have CHECK constraint to ensure only the values we want to have in the table are there.

Using a number to represent the staus

 CREATE TABLE STATUS_TAB   (prim_key number,   otherdata VARCHAR2, etc...   STATUS number NOT NULL);

In this scenario, a 0 would represent “NOT YET PROCESSED” and a 1 would represent “COMPLETE”. Much better, but changing status from 0 to 1 will increase the size of your row by 1 byte.

“0” takes 1 byte to store in Oracle.
“1” takes 2 bytes to store.

You could cause some possible row migrations, and increase your storage requirement from 1GB to 2 GB for this column.

We would need a small second table STATUS_DESCRIPTION with a foreign key relationship, to explain the status and keep everything nice and relational with good data integrity.

Using a single character for the status

 CREATE TABLE STATUS_TAB   (prim_key number,   otherdata VARCHAR2, etc...   STATUS varchar2(1) NOT NULL);

Now, an “N” would represent “NOT YET PROCESSED” and a “C” would represent “COMPLETE”. Even better, now it’s just 1 byte to store your character, regardless of status. You still need 1 GB to store this data though.

We would need a small second table STATUS_DESCRIPTION as before.

Histograms: assuming you wish to query via the status, we need to allow Oracle to create a frequency Histogram on the indexed column in all scenario’s above, the optimizer would understand that there are very few values for the “not yet processed” status and many for “complete”, meaning that the index could be used when querying for the rare values. Without the histogram, the index is unlikely to be used for any value as Oracle would assume a 50/50 split between the 2 values and 500,000,000 single block lookups from the index isn’t going to be a selected access path.

Using NULL to represent COMPLETE

 CREATE TABLE STATUS_TAB   (prim_key number,    otherdata VARCHAR2, etc...   STATUS varchar2(1) ) ;

Now, an “O” would represent “NOT YET PROCESSED” and “NULL” would represent “COMPLETE”. Now it’s just 1 byte to store your character before you process the data and NO bytes to store it when you are complete, assuming there are no columns in the table following the STATUs column. Oracle does not store NULLs at the end of a table if they are not there.

Better still, because NULL’s are not stored within B-Tree indexes within Oracle, and I suspect the query “show me what I need to process” is a lot more common than “show me what I have processed”, putting an index on a 1,000,000,000 row table with 1,000 unprocessed rows will result in an index containing 1000 bytes (plus 10 byte rowid per entry, plus block overhead).

That’s not a very big index – a couple of blocks for a potentially huge table and would be extremely quick to read. When querying for a value which is not NULL, the index would be very useful.

We would need a small second table STATUS_DESCRIPTION as before.

Using BOOLEAN type

 CREATE TABLE STATUS_TAB   (prim_key number,    otherdata VARCHAR2, etc...   STATUS BOOLEAN ) ;

If you ony have 2 status levels, and will definitely not have more than 2, you could use the BOOLEAN type to store the status. This gives a TRUE or FALSE option but, and this is important in this context, a BOOLEAN takles 1 bytes to store and still has a length byte so it’s no more efficient from a storage perspective, and somewhat less flexible.

Caveat: All sizes are very approximate and don’t account for block overhead, length byte per column and – in an index – the storage of the ROWID, which takes 10 bytes per entry.

#ai #data #dataModel #database #design #flag #lowCardinality #model #null #oracle #sql #status #technology

#ai #data #datamodel #database #design #flag

Neil Chandler's DB Blog @[email protected] · 2026-08-23 · 23:14 UTC

“Status” columns in Oracle

I wrote this blog post a while ago, and I’ve just spotted it in the backlog drafts, so I though it might be time to publish it. This may be old news to many of you, but I sometimes work on systems where consideration for how to store STATUS columns (or more accurately, columns with low cardinality / few values) at the design stage would have saved an awful lot of problems.

In the scenario where you are recording the status of an action within an Oracle table, there are many ways to accomplish it. However, some ways are better than others.

Let us say that we have 2 statuses; “NOT YET PROCESSED” and “COMPLETE”.

Let us also assume a 1,000,000,000 rows table for sizing purposes, with 1,000 rows “NOT YET PROCESSED” and all of the rest set to “COMPLETE”.

We could store and index these in several different ways:

Storing a descriptive status

 CREATE TABLE STATUS_TAB  (prim_key NUMBER,   otherdata VARCHAR2, etc...   STATUS VARCHAR2(20) NOT NULL );

We could store the values as they are represented above. Very descriptive, but it will waste a lot of space.
Storing the word “COMPLETE” one billion times will take about 7.5 GB.

There’s also no guarantee that you will have good data integrity – the data is not being validated against a STATUS_DESCRIPTION, so we should also have CHECK constraint to ensure only the values we want to have in the table are there.

Using a number to represent the staus

 CREATE TABLE STATUS_TAB   (prim_key number,   otherdata VARCHAR2, etc...   STATUS number NOT NULL);

In this scenario, a 0 would represent “NOT YET PROCESSED” and a 1 would represent “COMPLETE”. Much better, but changing status from 0 to 1 will increase the size of your row by 1 byte.

“0” takes 1 byte to store in Oracle.
“1” takes 2 bytes to store.

You could cause some possible row migrations, and increase your storage requirement from 1GB to 2 GB for this column.

We would need a small second table STATUS_DESCRIPTION with a foreign key relationship, to explain the status and keep everything nice and relational with good data integrity.

Using a single character for the status

 CREATE TABLE STATUS_TAB   (prim_key number,   otherdata VARCHAR2, etc...   STATUS varchar2(1) NOT NULL);

Now, an “N” would represent “NOT YET PROCESSED” and a “C” would represent “COMPLETE”. Even better, now it’s just 1 byte to store your character, regardless of status. You still need 1 GB to store this data though.

We would need a small second table STATUS_DESCRIPTION as before.

Histograms: assuming you wish to query via the status, we need to allow Oracle to create a frequency Histogram on the indexed column in all scenario’s above, the optimizer would understand that there are very few values for the “not yet processed” status and many for “complete”, meaning that the index could be used when querying for the rare values. Without the histogram, the index is unlikely to be used for any value as Oracle would assume a 50/50 split between the 2 values and 500,000,000 single block lookups from the index isn’t going to be a selected access path.

Using NULL to represent COMPLETE

 CREATE TABLE STATUS_TAB   (prim_key number,    otherdata VARCHAR2, etc...   STATUS varchar2(1) ) ;

Now, an “O” would represent “NOT YET PROCESSED” and “NULL” would represent “COMPLETE”. Now it’s just 1 byte to store your character before you process the data and NO bytes to store it when you are complete, assuming there are no columns in the table following the STATUs column. Oracle does not store NULLs at the end of a table if they are not there.

Better still, because NULL’s are not stored within B-Tree indexes within Oracle, and I suspect the query “show me what I need to process” is a lot more common than “show me what I have processed”, putting an index on a 1,000,000,000 row table with 1,000 unprocessed rows will result in an index containing 1000 bytes (plus 10 byte rowid per entry, plus block overhead).

That’s not a very big index – a couple of blocks for a potentially huge table and would be extremely quick to read. When querying for a value which is not NULL, the index would be very useful.

We would need a small second table STATUS_DESCRIPTION as before.

Using BOOLEAN type

 CREATE TABLE STATUS_TAB   (prim_key number,    otherdata VARCHAR2, etc...   STATUS BOOLEAN ) ;

If you ony have 2 status levels, and will definitely not have more than 2, you could use the BOOLEAN type to store the status. This gives a TRUE or FALSE option but, and this is important in this context, a BOOLEAN takles 1 bytes to store and still has a length byte so it’s no more efficient from a storage perspective, and somewhat less flexible.

Caveat: All sizes are very approximate and don’t account for block overhead, length byte per column and – in an index – the storage of the ROWID, which takes 10 bytes per entry.

#ai #data #dataModel #database #design #flag #lowCardinality #model #null #oracle #sql #status #technology

#ai #data #datamodel #database #design #flag

Neil Chandler's DB Blog @[email protected] · 2026-08-23 · 23:14 UTC

“Status” columns in Oracle

I wrote this blog post a while ago, and I’ve just spotted it in the backlog drafts, so I though it might be time to publish it. This may be old news to many of you, but I sometimes work on systems where consideration for how to store STATUS columns (or more accurately, columns with low cardinality / few values) at the design stage would have saved an awful lot of problems.

In the scenario where you are recording the status of an action within an Oracle table, there are many ways to accomplish it. However, some ways are better than others.

Let us say that we have 2 statuses; “NOT YET PROCESSED” and “COMPLETE”.

Let us also assume a 1,000,000,000 rows table for sizing purposes, with 1,000 rows “NOT YET PROCESSED” and all of the rest set to “COMPLETE”.

We could store and index these in several different ways:

Storing a descriptive status

 CREATE TABLE STATUS_TAB  (prim_key NUMBER,   otherdata VARCHAR2, etc...   STATUS VARCHAR2(20) NOT NULL );

We could store the values as they are represented above. Very descriptive, but it will waste a lot of space.
Storing the word “COMPLETE” one billion times will take about 7.5 GB.

There’s also no guarantee that you will have good data integrity – the data is not being validated against a STATUS_DESCRIPTION, so we should also have CHECK constraint to ensure only the values we want to have in the table are there.

Using a number to represent the staus

 CREATE TABLE STATUS_TAB   (prim_key number,   otherdata VARCHAR2, etc...   STATUS number NOT NULL);

In this scenario, a 0 would represent “NOT YET PROCESSED” and a 1 would represent “COMPLETE”. Much better, but changing status from 0 to 1 will increase the size of your row by 1 byte.

“0” takes 1 byte to store in Oracle.
“1” takes 2 bytes to store.

You could cause some possible row migrations, and increase your storage requirement from 1GB to 2 GB for this column.

We would need a small second table STATUS_DESCRIPTION with a foreign key relationship, to explain the status and keep everything nice and relational with good data integrity.

Using a single character for the status

 CREATE TABLE STATUS_TAB   (prim_key number,   otherdata VARCHAR2, etc...   STATUS varchar2(1) NOT NULL);

Now, an “N” would represent “NOT YET PROCESSED” and a “C” would represent “COMPLETE”. Even better, now it’s just 1 byte to store your character, regardless of status. You still need 1 GB to store this data though.

We would need a small second table STATUS_DESCRIPTION as before.

Histograms: assuming you wish to query via the status, we need to allow Oracle to create a frequency Histogram on the indexed column in all scenario’s above, the optimizer would understand that there are very few values for the “not yet processed” status and many for “complete”, meaning that the index could be used when querying for the rare values. Without the histogram, the index is unlikely to be used for any value as Oracle would assume a 50/50 split between the 2 values and 500,000,000 single block lookups from the index isn’t going to be a selected access path.

Using NULL to represent COMPLETE

 CREATE TABLE STATUS_TAB   (prim_key number,    otherdata VARCHAR2, etc...   STATUS varchar2(1) ) ;

Now, an “O” would represent “NOT YET PROCESSED” and “NULL” would represent “COMPLETE”. Now it’s just 1 byte to store your character before you process the data and NO bytes to store it when you are complete, assuming there are no columns in the table following the STATUs column. Oracle does not store NULLs at the end of a table if they are not there.

Better still, because NULL’s are not stored within B-Tree indexes within Oracle, and I suspect the query “show me what I need to process” is a lot more common than “show me what I have processed”, putting an index on a 1,000,000,000 row table with 1,000 unprocessed rows will result in an index containing 1000 bytes (plus 10 byte rowid per entry, plus block overhead).

That’s not a very big index – a couple of blocks for a potentially huge table and would be extremely quick to read. When querying for a value which is not NULL, the index would be very useful.

We would need a small second table STATUS_DESCRIPTION as before.

Using BOOLEAN type

 CREATE TABLE STATUS_TAB   (prim_key number,    otherdata VARCHAR2, etc...   STATUS BOOLEAN ) ;

If you ony have 2 status levels, and will definitely not have more than 2, you could use the BOOLEAN type to store the status. This gives a TRUE or FALSE option but, and this is important in this context, a BOOLEAN takles 1 bytes to store and still has a length byte so it’s no more efficient from a storage perspective, and somewhat less flexible.

Caveat: All sizes are very approximate and don’t account for block overhead, length byte per column and – in an index – the storage of the ROWID, which takes 10 bytes per entry.

#ai #data #dataModel #database #design #flag #lowCardinality #model #null #oracle #sql #status #technology

#ai #data #datamodel #database #design #flag

Neil Chandler's DB Blog @[email protected] · 2026-08-23 · 23:14 UTC

“Status” columns in Oracle

I wrote this blog post a while ago, and I’ve just spotted it in the backlog drafts, so I though it might be time to publish it. This may be old news to many of you, but I sometimes work on systems where consideration for how to store STATUS columns (or more accurately, columns with low cardinality / few values) at the design stage would have saved an awful lot of problems.

In the scenario where you are recording the status of an action within an Oracle table, there are many ways to accomplish it. However, some ways are better than others.

Let us say that we have 2 statuses; “NOT YET PROCESSED” and “COMPLETE”.

Let us also assume a 1,000,000,000 rows table for sizing purposes, with 1,000 rows “NOT YET PROCESSED” and all of the rest set to “COMPLETE”.

We could store and index these in several different ways:

Storing a descriptive status

 CREATE TABLE STATUS_TAB  (prim_key NUMBER,   otherdata VARCHAR2, etc...   STATUS VARCHAR2(20) NOT NULL );

We could store the values as they are represented above. Very descriptive, but it will waste a lot of space.
Storing the word “COMPLETE” one billion times will take about 7.5 GB.

There’s also no guarantee that you will have good data integrity – the data is not being validated against a STATUS_DESCRIPTION, so we should also have CHECK constraint to ensure only the values we want to have in the table are there.

Using a number to represent the staus

 CREATE TABLE STATUS_TAB   (prim_key number,   otherdata VARCHAR2, etc...   STATUS number NOT NULL);

In this scenario, a 0 would represent “NOT YET PROCESSED” and a 1 would represent “COMPLETE”. Much better, but changing status from 0 to 1 will increase the size of your row by 1 byte.

“0” takes 1 byte to store in Oracle.
“1” takes 2 bytes to store.

You could cause some possible row migrations, and increase your storage requirement from 1GB to 2 GB for this column.

We would need a small second table STATUS_DESCRIPTION with a foreign key relationship, to explain the status and keep everything nice and relational with good data integrity.

Using a single character for the status

 CREATE TABLE STATUS_TAB   (prim_key number,   otherdata VARCHAR2, etc...   STATUS varchar2(1) NOT NULL);

Now, an “N” would represent “NOT YET PROCESSED” and a “C” would represent “COMPLETE”. Even better, now it’s just 1 byte to store your character, regardless of status. You still need 1 GB to store this data though.

We would need a small second table STATUS_DESCRIPTION as before.

Histograms: assuming you wish to query via the status, we need to allow Oracle to create a frequency Histogram on the indexed column in all scenario’s above, the optimizer would understand that there are very few values for the “not yet processed” status and many for “complete”, meaning that the index could be used when querying for the rare values. Without the histogram, the index is unlikely to be used for any value as Oracle would assume a 50/50 split between the 2 values and 500,000,000 single block lookups from the index isn’t going to be a selected access path.

Using NULL to represent COMPLETE

 CREATE TABLE STATUS_TAB   (prim_key number,    otherdata VARCHAR2, etc...   STATUS varchar2(1) ) ;

Now, an “O” would represent “NOT YET PROCESSED” and “NULL” would represent “COMPLETE”. Now it’s just 1 byte to store your character before you process the data and NO bytes to store it when you are complete, assuming there are no columns in the table following the STATUs column. Oracle does not store NULLs at the end of a table if they are not there.

Better still, because NULL’s are not stored within B-Tree indexes within Oracle, and I suspect the query “show me what I need to process” is a lot more common than “show me what I have processed”, putting an index on a 1,000,000,000 row table with 1,000 unprocessed rows will result in an index containing 1000 bytes (plus 10 byte rowid per entry, plus block overhead).

That’s not a very big index – a couple of blocks for a potentially huge table and would be extremely quick to read. When querying for a value which is not NULL, the index would be very useful.

We would need a small second table STATUS_DESCRIPTION as before.

Using BOOLEAN type

 CREATE TABLE STATUS_TAB   (prim_key number,    otherdata VARCHAR2, etc...   STATUS BOOLEAN ) ;

If you ony have 2 status levels, and will definitely not have more than 2, you could use the BOOLEAN type to store the status. This gives a TRUE or FALSE option but, and this is important in this context, a BOOLEAN takles 1 bytes to store and still has a length byte so it’s no more efficient from a storage perspective, and somewhat less flexible.

Caveat: All sizes are very approximate and don’t account for block overhead, length byte per column and – in an index – the storage of the ROWID, which takes 10 bytes per entry.

#ai #data #dataModel #database #design #flag #lowCardinality #model #null #oracle #sql #status #technology

#technology #status #sql #oracle #null #model

Neil Chandler's DB Blog @[email protected] · 2026-08-23 · 23:14 UTC

“Status” columns in Oracle

I wrote this blog post a while ago, and I’ve just spotted it in the backlog drafts, so I though it might be time to publish it. This may be old news to many of you, but I sometimes work on systems where consideration for how to store STATUS columns (or more accurately, columns with low cardinality / few values) at the design stage would have saved an awful lot of problems.

In the scenario where you are recording the status of an action within an Oracle table, there are many ways to accomplish it. However, some ways are better than others.

Let us say that we have 2 statuses; “NOT YET PROCESSED” and “COMPLETE”.

Let us also assume a 1,000,000,000 rows table for sizing purposes, with 1,000 rows “NOT YET PROCESSED” and all of the rest set to “COMPLETE”.

We could store and index these in several different ways:

Storing a descriptive status

 CREATE TABLE STATUS_TAB  (prim_key NUMBER,   otherdata VARCHAR2, etc...   STATUS VARCHAR2(20) NOT NULL );

We could store the values as they are represented above. Very descriptive, but it will waste a lot of space.
Storing the word “COMPLETE” one billion times will take about 7.5 GB.

There’s also no guarantee that you will have good data integrity – the data is not being validated against a STATUS_DESCRIPTION, so we should also have CHECK constraint to ensure only the values we want to have in the table are there.

Using a number to represent the staus

 CREATE TABLE STATUS_TAB   (prim_key number,   otherdata VARCHAR2, etc...   STATUS number NOT NULL);

In this scenario, a 0 would represent “NOT YET PROCESSED” and a 1 would represent “COMPLETE”. Much better, but changing status from 0 to 1 will increase the size of your row by 1 byte.

“0” takes 1 byte to store in Oracle.
“1” takes 2 bytes to store.

You could cause some possible row migrations, and increase your storage requirement from 1GB to 2 GB for this column.

We would need a small second table STATUS_DESCRIPTION with a foreign key relationship, to explain the status and keep everything nice and relational with good data integrity.

Using a single character for the status

 CREATE TABLE STATUS_TAB   (prim_key number,   otherdata VARCHAR2, etc...   STATUS varchar2(1) NOT NULL);

Now, an “N” would represent “NOT YET PROCESSED” and a “C” would represent “COMPLETE”. Even better, now it’s just 1 byte to store your character, regardless of status. You still need 1 GB to store this data though.

We would need a small second table STATUS_DESCRIPTION as before.

Histograms: assuming you wish to query via the status, we need to allow Oracle to create a frequency Histogram on the indexed column in all scenario’s above, the optimizer would understand that there are very few values for the “not yet processed” status and many for “complete”, meaning that the index could be used when querying for the rare values. Without the histogram, the index is unlikely to be used for any value as Oracle would assume a 50/50 split between the 2 values and 500,000,000 single block lookups from the index isn’t going to be a selected access path.

Using NULL to represent COMPLETE

 CREATE TABLE STATUS_TAB   (prim_key number,    otherdata VARCHAR2, etc...   STATUS varchar2(1) ) ;

Now, an “O” would represent “NOT YET PROCESSED” and “NULL” would represent “COMPLETE”. Now it’s just 1 byte to store your character before you process the data and NO bytes to store it when you are complete, assuming there are no columns in the table following the STATUs column. Oracle does not store NULLs at the end of a table if they are not there.

Better still, because NULL’s are not stored within B-Tree indexes within Oracle, and I suspect the query “show me what I need to process” is a lot more common than “show me what I have processed”, putting an index on a 1,000,000,000 row table with 1,000 unprocessed rows will result in an index containing 1000 bytes (plus 10 byte rowid per entry, plus block overhead).

That’s not a very big index – a couple of blocks for a potentially huge table and would be extremely quick to read. When querying for a value which is not NULL, the index would be very useful.

We would need a small second table STATUS_DESCRIPTION as before.

Using BOOLEAN type

 CREATE TABLE STATUS_TAB   (prim_key number,    otherdata VARCHAR2, etc...   STATUS BOOLEAN ) ;

If you ony have 2 status levels, and will definitely not have more than 2, you could use the BOOLEAN type to store the status. This gives a TRUE or FALSE option but, and this is important in this context, a BOOLEAN takles 1 bytes to store and still has a length byte so it’s no more efficient from a storage perspective, and somewhat less flexible.

Caveat: All sizes are very approximate and don’t account for block overhead, length byte per column and – in an index – the storage of the ROWID, which takes 10 bytes per entry.

#ai #data #dataModel #database #design #flag #lowCardinality #model #null #oracle #sql #status #technology

#ai #data #datamodel #database #design #flag

Peoplewoo Skills @[email protected] · 2026-08-07 · 13:43 UTC

Watch Now: https://zurl.co/PKg08

Linking Orders DE to Loyalty DE (One-to-One) in Salesforce Marketing Cloud | Contact Builder Tutorial

#Salesforce #SalesforceMarketingCloud #SFMC #ContactBuilder #OrdersDE #LoyaltyDE #DataExtension #OneToOneRelationship #DataModel #JourneyBuilder #MarketingAutomation #EmailMarketing #CRM #SalesforceTutorial #PeopleWoo #SalesforceDeveloper #LearnSFMC #MarketingCloudTutorial #SalesforceCertification #TechTutorial

#salesforce #salesforcemarketingcloud #sfmc #contactbuilder #ordersde #loyaltyde

Peoplewoo Skills @[email protected] · 2026-08-07 · 13:43 UTC

Watch Now: https://zurl.co/PKg08

Linking Orders DE to Loyalty DE (One-to-One) in Salesforce Marketing Cloud | Contact Builder Tutorial

#Salesforce #SalesforceMarketingCloud #SFMC #ContactBuilder #OrdersDE #LoyaltyDE #DataExtension #OneToOneRelationship #DataModel #JourneyBuilder #MarketingAutomation #EmailMarketing #CRM #SalesforceTutorial #PeopleWoo #SalesforceDeveloper #LearnSFMC #MarketingCloudTutorial #SalesforceCertification #TechTutorial

#techtutorial #salesforcecertification #marketingcloudtutorial #learnsfmc #salesforcedeveloper #peoplewoo

Peoplewoo Skills @[email protected] · 2026-08-07 · 12:01 UTC

Watch Now: https://zurl.co/SHI6q

Linking a Master DE to Contact Key (1-to-1 Relationship) in Salesforce Marketing Cloud | SFMC Tutorial

#Salesforce #SalesforceMarketingCloud #SFMC #ContactBuilder #DataExtension #ContactKey #MasterDataExtension #JourneyBuilder #MarketingAutomation #EmailMarketing #CRM #SalesforceTutorial #SFMCTraining #PeopleWoo #SalesforceDeveloper #MarketingCloudTutorial #LearnSFMC #DataModel #SalesforceCertification #TechTutorial

#salesforce #salesforcemarketingcloud #sfmc #contactbuilder #dataextension #contactkey

Peoplewoo Skills @[email protected] · 2026-08-07 · 12:01 UTC

Watch Now: https://zurl.co/SHI6q

Linking a Master DE to Contact Key (1-to-1 Relationship) in Salesforce Marketing Cloud | SFMC Tutorial

#Salesforce #SalesforceMarketingCloud #SFMC #ContactBuilder #DataExtension #ContactKey #MasterDataExtension #JourneyBuilder #MarketingAutomation #EmailMarketing #CRM #SalesforceTutorial #SFMCTraining #PeopleWoo #SalesforceDeveloper #MarketingCloudTutorial #LearnSFMC #DataModel #SalesforceCertification #TechTutorial

#techtutorial #salesforcecertification #datamodel #learnsfmc #marketingcloudtutorial #salesforcedeveloper

RedPacket Security @[email protected] · 2026-07-26 · 09:49 UTC

CVE Alert: CVE-2026-63720 - koxudaxi - datamodel-code-generator - https://www.redpacketsecurity.com/cve-alert-cve-2026-63720-koxudaxi-datamodel-code-generator/

#OSINT #ThreatIntel #CyberSecurity #cve-2026-63720 #koxudaxi #datamodel-code-generator

#osint #threatintel #cybersecurity #cve #koxudaxi #datamodel

RedPacket Security @[email protected] · 2026-07-26 · 09:49 UTC

CVE Alert: CVE-2026-63720 - koxudaxi - datamodel-code-generator - https://www.redpacketsecurity.com/cve-alert-cve-2026-63720-koxudaxi-datamodel-code-generator/

#OSINT #ThreatIntel #CyberSecurity #cve-2026-63720 #koxudaxi #datamodel-code-generator

#osint #threatintel #cybersecurity #cve #koxudaxi #datamodel

RedPacket Security @[email protected] · 2026-07-26 · 09:49 UTC

CVE Alert: CVE-2026-63720 - koxudaxi - datamodel-code-generator - https://www.redpacketsecurity.com/cve-alert-cve-2026-63720-koxudaxi-datamodel-code-generator/

#OSINT #ThreatIntel #CyberSecurity #cve-2026-63720 #koxudaxi #datamodel-code-generator

#osint #threatintel #cybersecurity #cve #koxudaxi #datamodel

RedPacket Security @[email protected] · 2026-07-26 · 09:49 UTC

CVE Alert: CVE-2026-63720 - koxudaxi - datamodel-code-generator - https://www.redpacketsecurity.com/cve-alert-cve-2026-63720-koxudaxi-datamodel-code-generator/

#OSINT #ThreatIntel #CyberSecurity #cve-2026-63720 #koxudaxi #datamodel-code-generator

#datamodel #koxudaxi #cve #cybersecurity #threatintel #osint

RedPacket Security @[email protected] · 2026-07-26 · 09:49 UTC

CVE Alert: CVE-2026-63720 - koxudaxi - datamodel-code-generator - https://www.redpacketsecurity.com/cve-alert-cve-2026-63720-koxudaxi-datamodel-code-generator/

#OSINT #ThreatIntel #CyberSecurity #cve-2026-63720 #koxudaxi #datamodel-code-generator

#osint #threatintel #cybersecurity #cve #koxudaxi #datamodel

Peoplewoo Skills @[email protected] · 2026-07-24 · 12:25 UTC

watch now : https://zurl.co/7Icq7

Mapping Data Lake Objects (DLO) to Custom DMOs in Salesforce Data Cloud | Complete Step-by-Step Guide

#Salesforce #SalesforceDataCloud #DataCloud #DataLakeObject #DLO #DMO #CustomDMO #DataModel #Customer360 #CRM #SalesforceDeveloper #SalesforceAdmin #DataEngineering #DataIntegration #Trailhead #SalesforceTutorial #PeoplewooSkills #Learning #TechTutorial #CloudComputing

#salesforce #salesforcedatacloud #datacloud #datalakeobject #dlo #dmo

Peoplewoo Skills @[email protected] · 2026-07-24 · 12:25 UTC

watch now : https://zurl.co/7Icq7

Mapping Data Lake Objects (DLO) to Custom DMOs in Salesforce Data Cloud | Complete Step-by-Step Guide

#Salesforce #SalesforceDataCloud #DataCloud #DataLakeObject #DLO #DMO #CustomDMO #DataModel #Customer360 #CRM #SalesforceDeveloper #SalesforceAdmin #DataEngineering #DataIntegration #Trailhead #SalesforceTutorial #PeoplewooSkills #Learning #TechTutorial #CloudComputing

#salesforce #salesforcedatacloud #datacloud #datalakeobject #dlo #dmo

Peoplewoo Skills @[email protected] · 2026-07-24 · 12:25 UTC

watch now : https://zurl.co/7Icq7

Mapping Data Lake Objects (DLO) to Custom DMOs in Salesforce Data Cloud | Complete Step-by-Step Guide

#Salesforce #SalesforceDataCloud #DataCloud #DataLakeObject #DLO #DMO #CustomDMO #DataModel #Customer360 #CRM #SalesforceDeveloper #SalesforceAdmin #DataEngineering #DataIntegration #Trailhead #SalesforceTutorial #PeoplewooSkills #Learning #TechTutorial #CloudComputing

#salesforce #salesforcedatacloud #datacloud #datalakeobject #dlo #dmo

Peoplewoo Skills @[email protected] · 2026-07-24 · 12:25 UTC

watch now : https://zurl.co/7Icq7

Mapping Data Lake Objects (DLO) to Custom DMOs in Salesforce Data Cloud | Complete Step-by-Step Guide

#Salesforce #SalesforceDataCloud #DataCloud #DataLakeObject #DLO #DMO #CustomDMO #DataModel #Customer360 #CRM #SalesforceDeveloper #SalesforceAdmin #DataEngineering #DataIntegration #Trailhead #SalesforceTutorial #PeoplewooSkills #Learning #TechTutorial #CloudComputing

#cloudcomputing #techtutorial #learning #peoplewooskills #salesforcetutorial #trailhead

Peoplewoo Skills @[email protected] · 2026-07-24 · 12:25 UTC

watch now : https://zurl.co/7Icq7

Mapping Data Lake Objects (DLO) to Custom DMOs in Salesforce Data Cloud | Complete Step-by-Step Guide

#Salesforce #SalesforceDataCloud #DataCloud #DataLakeObject #DLO #DMO #CustomDMO #DataModel #Customer360 #CRM #SalesforceDeveloper #SalesforceAdmin #DataEngineering #DataIntegration #Trailhead #SalesforceTutorial #PeoplewooSkills #Learning #TechTutorial #CloudComputing

#salesforce #salesforcedatacloud #datacloud #datalakeobject #dlo #dmo

Peoplewoo Skills @[email protected] · 2026-07-10 · 15:36 UTC

Watch Now: https://zurl.co/s0QN5

Why Identity Resolution is Crucial in Salesforce Data Cloud | Complete Beginner's Guide

#Salesforce #SalesforceDataCloud #IdentityResolution #Customer360 #DataCloud #SalesforceTutorial #SalesforceDeveloper #SalesforceAdmin #DataModel #CustomerDataPlatform #CDP #SalesforceInterview #Peoplewoo

#salesforce #salesforcedatacloud #identityresolution #customer360 #datacloud #salesforcetutorial

Peoplewoo Skills @[email protected] · 2026-07-10 · 15:36 UTC

Watch Now: https://zurl.co/s0QN5

Why Identity Resolution is Crucial in Salesforce Data Cloud | Complete Beginner's Guide

#Salesforce #SalesforceDataCloud #IdentityResolution #Customer360 #DataCloud #SalesforceTutorial #SalesforceDeveloper #SalesforceAdmin #DataModel #CustomerDataPlatform #CDP #SalesforceInterview #Peoplewoo

#salesforce #salesforcedatacloud #identityresolution #customer360 #datacloud #salesforcetutorial

Peoplewoo Skills @[email protected] · 2026-07-10 · 15:36 UTC

Watch Now: https://zurl.co/s0QN5

Why Identity Resolution is Crucial in Salesforce Data Cloud | Complete Beginner's Guide

#Salesforce #SalesforceDataCloud #IdentityResolution #Customer360 #DataCloud #SalesforceTutorial #SalesforceDeveloper #SalesforceAdmin #DataModel #CustomerDataPlatform #CDP #SalesforceInterview #Peoplewoo

#peoplewoo #salesforceinterview #cdp #customerdataplatform #datamodel #salesforceadmin

Peoplewoo Skills @[email protected] · 2026-07-10 · 15:36 UTC

Watch Now: https://zurl.co/s0QN5

Why Identity Resolution is Crucial in Salesforce Data Cloud | Complete Beginner's Guide

#Salesforce #SalesforceDataCloud #IdentityResolution #Customer360 #DataCloud #SalesforceTutorial #SalesforceDeveloper #SalesforceAdmin #DataModel #CustomerDataPlatform #CDP #SalesforceInterview #Peoplewoo

#salesforce #salesforcedatacloud #identityresolution #customer360 #datacloud #salesforcetutorial

Peoplewoo Skills @[email protected] · 2026-07-10 · 13:10 UTC

Watch Now: https://zurl.co/91FOJ

Party Identification & Foreign Keys in Salesforce Data Cloud | Complete Beginner Tutorial

#Salesforce #SalesforceDataCloud #DataCloud #PartyIdentification #ForeignKeys #Customer360 #DataModel #DataModeling #CRM #SalesforceTutorial #DataCloudTutorial #SalesforceDeveloper #DataEngineering #IdentityResolution #Peoplewoo

#peoplewoo #identityresolution #dataengineering #salesforcedeveloper #datacloudtutorial #salesforcetutorial

Peoplewoo Skills @[email protected] · 2026-07-09 · 10:30 UTC

Watch Now: https://zurl.co/c7Gku

Contact Based Data Model in Salesforce Marketing Cloud Explained | SFMC Contact Model Tutorial

#Salesforce #SFMC #MarketingCloud #ContactBuilder #DataModel #PeopleWoo

#peoplewoo #datamodel #contactbuilder #marketingcloud #sfmc #salesforce

Peoplewoo Skills @[email protected] · 2026-07-07 · 15:22 UTC

Watch Now: https://zurl.co/v89k4

Unified Link Individual Data Model Object in Salesforce Data Cloud (Data 360) | Complete Tutorial

#Salesforce #SalesforceDataCloud #Data360 #SalesforceData360 #UnifiedLinkIndividual #UnifiedIndividual #Customer360 #DataModel #DMO #IdentityResolution #CustomerProfile #SalesforceAdmin

#salesforceadmin #customerprofile #identityresolution #dmo #datamodel #customer360

Benjamin R @[email protected] · 2026-07-06 · 19:12 UTC

#rdf #linkeddata #LOD #datamodel
{3/n} But I really want something in the specs that states this requirement in a more hard and fast way and I'm not finding it. For example, RDF 1.1 Concepts and Abstract Syntax > 3.1 Triples doesn't come out and provide any req's for the predicate other than that it is an IRI.
I thought that perhaps The RDF Concepts Vocabulary (RDF namespace) properties for reifying triples might help, but -- to my surprise -- rdf:predicate has rdfs:range rdfs:Resource -- I expected this to be rdf:Property.
Thus, I'm not currently coming up with anything from the specs (thus, looking for wisdom -- entirely possible and in fact dependable that I am missing things), but rather, only what seems like convention.

#datamodel #lod #linkeddata #rdf

Benjamin R @[email protected] · 2026-07-06 · 19:12 UTC

#rdf #linkeddata #LOD #datamodel
{3/n} But I really want something in the specs that states this requirement in a more hard and fast way and I'm not finding it. For example, RDF 1.1 Concepts and Abstract Syntax > 3.1 Triples doesn't come out and provide any req's for the predicate other than that it is an IRI.
I thought that perhaps The RDF Concepts Vocabulary (RDF namespace) properties for reifying triples might help, but -- to my surprise -- rdf:predicate has rdfs:range rdfs:Resource -- I expected this to be rdf:Property.
Thus, I'm not currently coming up with anything from the specs (thus, looking for wisdom -- entirely possible and in fact dependable that I am missing things), but rather, only what seems like convention.

#datamodel #lod #linkeddata #rdf

Benjamin R @[email protected] · 2026-07-06 · 19:12 UTC

#rdf #linkeddata #LOD #datamodel
{3/n} But I really want something in the specs that states this requirement in a more hard and fast way and I'm not finding it. For example, RDF 1.1 Concepts and Abstract Syntax > 3.1 Triples doesn't come out and provide any req's for the predicate other than that it is an IRI.
I thought that perhaps The RDF Concepts Vocabulary (RDF namespace) properties for reifying triples might help, but -- to my surprise -- rdf:predicate has rdfs:range rdfs:Resource -- I expected this to be rdf:Property.
Thus, I'm not currently coming up with anything from the specs (thus, looking for wisdom -- entirely possible and in fact dependable that I am missing things), but rather, only what seems like convention.

#datamodel #lod #linkeddata #rdf

Benjamin R @briesenb · 2026-07-06 · 19:12 UTC

#rdf #linkeddata #LOD #datamodel
{3/n} But I really want something in the specs that states this requirement in a more hard and fast way and I'm not finding it. For example, RDF 1.1 Concepts and Abstract Syntax > 3.1 Triples doesn't come out and provide any req's for the predicate other than that it is an IRI.
I thought that perhaps The RDF Concepts Vocabulary (RDF namespace) properties for reifying triples might help, but -- to my surprise -- rdf:predicate has rdfs:range rdfs:Resource -- I expected this to be rdf:Property.
Thus, I'm not currently coming up with anything from the specs (thus, looking for wisdom -- entirely possible and in fact dependable that I am missing things), but rather, only what seems like convention.

#datamodel #lod #linkeddata #rdf

Benjamin R @[email protected] · 2026-07-06 · 19:12 UTC

#rdf #linkeddata #LOD #datamodel
{3/n} But I really want something in the specs that states this requirement in a more hard and fast way and I'm not finding it. For example, RDF 1.1 Concepts and Abstract Syntax > 3.1 Triples doesn't come out and provide any req's for the predicate other than that it is an IRI.
I thought that perhaps The RDF Concepts Vocabulary (RDF namespace) properties for reifying triples might help, but -- to my surprise -- rdf:predicate has rdfs:range rdfs:Resource -- I expected this to be rdf:Property.
Thus, I'm not currently coming up with anything from the specs (thus, looking for wisdom -- entirely possible and in fact dependable that I am missing things), but rather, only what seems like convention.

#datamodel #lod #linkeddata #rdf

Benjamin R @[email protected] · 2026-07-06 · 19:06 UTC

#rdf #linkeddata #LOD #datamodel
{2/n} I mean, I might explain this in a very non-technical way, like,
When you publish an RDF metadata description set you are creating a model with the triples. You are asserting that the subject of each triple has the attribute value of or relationship with the object.
If the predicate of the triple isn't something modelled in a way that makes this connection, it won't work well for various reasons (users likely won't query using predicates that aren't instances of rdf:Property or some subclass of that, would be the most important I think.)

#datamodel #lod #linkeddata #rdf

Benjamin R @[email protected] · 2026-07-06 · 19:06 UTC

#rdf #linkeddata #LOD #datamodel
{2/n} I mean, I might explain this in a very non-technical way, like,
When you publish an RDF metadata description set you are creating a model with the triples. You are asserting that the subject of each triple has the attribute value of or relationship with the object.
If the predicate of the triple isn't something modelled in a way that makes this connection, it won't work well for various reasons (users likely won't query using predicates that aren't instances of rdf:Property or some subclass of that, would be the most important I think.)

#datamodel #lod #linkeddata #rdf

Benjamin R @briesenb · 2026-07-06 · 19:06 UTC

#rdf #linkeddata #LOD #datamodel
{2/n} I mean, I might explain this in a very non-technical way, like,
When you publish an RDF metadata description set you are creating a model with the triples. You are asserting that the subject of each triple has the attribute value of or relationship with the object.
If the predicate of the triple isn't something modelled in a way that makes this connection, it won't work well for various reasons (users likely won't query using predicates that aren't instances of rdf:Property or some subclass of that, would be the most important I think.)

#datamodel #lod #linkeddata #rdf

Benjamin R @[email protected] · 2026-07-06 · 19:03 UTC

#rdf #linkeddata #LOD #datamodel

{ 1/n } Reviewing an RDF metadata application profile, came across an IRI used as a predicate in metadata description set triples, looked at modelling from the source:

```Turtle
<http://www.ebu.ch/metadata/ontologies/ebucore/ebucore#ContentAlert> a rdfs:Class ;
rdfs:label "Content alert"@en ;
rdfs:comment "To provide information about a particular type of content potentially sensitive."@en ;
rdfs:subClassOf <http://www.ebu.ch/metadata/ontologies/ebucore/ebucore#Type> .
```

Said something like "Oh, well, that's a class, we can't use that as a property, we'll want to change that."
Was asked the question "Why can't we use that IRI as a property?"
The fact that you can't use a resource that is an instance of rdfs:Class as a predicate in an RDF triple -- or, at least, you shouldn't -- seemed self-evident to me. But I found I was somewhat at a loss to come up with what I consider a solid response about why this is the case based in RDF specs.
Thus, here I am looking for wisdom on the internet.
To say a bit more...

#datamodel #lod #linkeddata #rdf

Benjamin R @[email protected] · 2026-07-06 · 19:03 UTC

#rdf #linkeddata #LOD #datamodel

{ 1/n } Reviewing an RDF metadata application profile, came across an IRI used as a predicate in metadata description set triples, looked at modelling from the source:

```Turtle
<http://www.ebu.ch/metadata/ontologies/ebucore/ebucore#ContentAlert> a rdfs:Class ;
rdfs:label "Content alert"@en ;
rdfs:comment "To provide information about a particular type of content potentially sensitive."@en ;
rdfs:subClassOf <http://www.ebu.ch/metadata/ontologies/ebucore/ebucore#Type> .
```

Said something like "Oh, well, that's a class, we can't use that as a property, we'll want to change that."
Was asked the question "Why can't we use that IRI as a property?"
The fact that you can't use a resource that is an instance of rdfs:Class as a predicate in an RDF triple -- or, at least, you shouldn't -- seemed self-evident to me. But I found I was somewhat at a loss to come up with what I consider a solid response about why this is the case based in RDF specs.
Thus, here I am looking for wisdom on the internet.
To say a bit more...

#datamodel #lod #linkeddata #rdf

Benjamin R @[email protected] · 2026-07-06 · 19:03 UTC

#rdf #linkeddata #LOD #datamodel

{ 1/n } Reviewing an RDF metadata application profile, came across an IRI used as a predicate in metadata description set triples, looked at modelling from the source:

```Turtle
<http://www.ebu.ch/metadata/ontologies/ebucore/ebucore#ContentAlert> a rdfs:Class ;
rdfs:label "Content alert"@en ;
rdfs:comment "To provide information about a particular type of content potentially sensitive."@en ;
rdfs:subClassOf <http://www.ebu.ch/metadata/ontologies/ebucore/ebucore#Type> .
```

Said something like "Oh, well, that's a class, we can't use that as a property, we'll want to change that."
Was asked the question "Why can't we use that IRI as a property?"
The fact that you can't use a resource that is an instance of rdfs:Class as a predicate in an RDF triple -- or, at least, you shouldn't -- seemed self-evident to me. But I found I was somewhat at a loss to come up with what I consider a solid response about why this is the case based in RDF specs.
Thus, here I am looking for wisdom on the internet.
To say a bit more...

#datamodel #lod #linkeddata #rdf

Benjamin R @briesenb · 2026-07-06 · 19:03 UTC

#rdf #linkeddata #LOD #datamodel

{ 1/n } Reviewing an RDF metadata application profile, came across an IRI used as a predicate in metadata description set triples, looked at modelling from the source:

```Turtle
<http://www.ebu.ch/metadata/ontologies/ebucore/ebucore#ContentAlert> a rdfs:Class ;
rdfs:label "Content alert"@en ;
rdfs:comment "To provide information about a particular type of content potentially sensitive."@en ;
rdfs:subClassOf <http://www.ebu.ch/metadata/ontologies/ebucore/ebucore#Type> .
```

Said something like "Oh, well, that's a class, we can't use that as a property, we'll want to change that."
Was asked the question "Why can't we use that IRI as a property?"
The fact that you can't use a resource that is an instance of rdfs:Class as a predicate in an RDF triple -- or, at least, you shouldn't -- seemed self-evident to me. But I found I was somewhat at a loss to come up with what I consider a solid response about why this is the case based in RDF specs.
Thus, here I am looking for wisdom on the internet.
To say a bit more...

#datamodel #lod #linkeddata #rdf

Benjamin R @[email protected] · 2026-07-06 · 19:03 UTC

#rdf #linkeddata #LOD #datamodel

{ 1/n } Reviewing an RDF metadata application profile, came across an IRI used as a predicate in metadata description set triples, looked at modelling from the source:

```Turtle
<http://www.ebu.ch/metadata/ontologies/ebucore/ebucore#ContentAlert> a rdfs:Class ;
rdfs:label "Content alert"@en ;
rdfs:comment "To provide information about a particular type of content potentially sensitive."@en ;
rdfs:subClassOf <http://www.ebu.ch/metadata/ontologies/ebucore/ebucore#Type> .
```

Said something like "Oh, well, that's a class, we can't use that as a property, we'll want to change that."
Was asked the question "Why can't we use that IRI as a property?"
The fact that you can't use a resource that is an instance of rdfs:Class as a predicate in an RDF triple -- or, at least, you shouldn't -- seemed self-evident to me. But I found I was somewhat at a loss to come up with what I consider a solid response about why this is the case based in RDF specs.
Thus, here I am looking for wisdom on the internet.
To say a bit more...

#datamodel #lod #linkeddata #rdf

M365Show @[email protected] · 2026-05-21 · 16:40 UTC

If you’re trusting your data in Microsoft Fabric to stay accurate just because you set it up perfectly the first time, you could be in for a rude awakening. Data model drift is a silent disruptor—find out what you can do today to prevent tomorrow’s problems.