Clarify limitations of text to numeric conversion

[eugman]

Sources:
https://www.sqlbi.com/articles/choosing-between-date-or-integer-to-represent-dates-in-power-bi-and-tabular/?hl=es-US https://www.maxwikstrom.se/performance/power-bi-data-types-in-relationships-does-it-matter/

[prmerger-automator]

@eugman : Thanks for your contribution! The author(s) and reviewer(s) have been notified to review your proposed change.

[learn-build-service-prod]

Learn Build status updates of commit df8967c:

✅ Validation status: passed

File	Status	Preview URL	Details
powerbi-docs/guidance/import-modeling-data-reduction.md	✅Succeeded

For more details, please refer to the build report.

[Copilot]

Pull request overview

This PR adds a clarification about the limitations of converting text data to numeric values for data reduction in Power BI Import models, specifically noting that such conversion provides no benefit when columns are used in relationships.

Key Change:

• Added a note explaining that text-to-numeric conversion doesn't reduce storage when columns are used in relationships, as they're always hash encoded

[Copilot]

The sentence structure is awkward with "does not help." Consider revising to: "Converting text data to numeric values doesn't help if the column is used in a relationship, because it's always hash encoded."

This improves readability by:

1. Using the contraction "doesn't" (consistent with Microsoft Writing Style Guide conversational tone)
2. Changing "the column is being used" to "the column is used" (simpler present tense)
3. Changing "it will always be" to "it's always" (more concise and uses present tense)

Suggested change

	Converting the text data to numeric values does not help if the column is being used in a relationship, because it will always be hash encoded.
	Converting text data to numeric values doesn't help if the column is used in a relationship, because it's always hash encoded.

[v-dirichards]

@denglishbi - The intent of the change in this PR seems to be not to fix the content but to raise an issue. You might want to close this PR and address the issue in a new PR in the private repo.

#label:"aq-pr-triaged"
@MicrosoftDocs/public-repo-pr-review-team

[eugman]

@denglishbi - The intent of the change in this PR seems to be not to fix the content but to raise an issue. You might want to close this PR and address the issue in a new PR in the private repo.

#label:"aq-pr-triaged" @MicrosoftDocs/public-repo-pr-review-team

Just to clarify, this is intended to add a clarification to the content, not to raise an issue with the DAX engine.

I was having a conversation on Reddit with a user who felt the docs contradicted the official behavior of the engine.
https://www.reddit.com/r/PowerBI/comments/1pcitfq/comment/nrzbryy/

[v-dirichards]

@eugman Ah ok, thanks for the clarification.

---

@denglishbi

Can you review the proposed changes?

Important: When the changes are ready for publication, adding a #sign-off comment is the best way to signal that the PR is ready for the review team to merge.

#label:"aq-pr-triaged"
@MicrosoftDocs/public-repo-pr-review-team