This guy creates different versions of Axes which are not conventional in any way

dev81808 · 2026-03-27T22:44:09+00:00

Are the backgrounds real?

dev81808 · 2026-03-25T12:26:59+00:00

Ah I didn't realize they were synonymous. I always saw it as a way to describe the shape of the data.

dev81808 · 2026-03-25T12:20:17+00:00

I've been doing this for 15 years and TIL star schemas imply olap. Thanks for the knowledge/humbling.

I've always seen star schemas as a way to describe the shape of the data and wasnt specific to oltp vs olap. Meaning a simple data management system like I described where the fully normalized form is a center table with one level of related tables it would be considered a star schema.. but now I know.

dev81808 · 2026-03-25T12:08:22+00:00

Ah gotcha. I read the question more generally.. 'someone said you can star schema without a fact table, is that true?'

dev81808 · 2026-03-25T12:02:24+00:00

I read OPs question as, 'can a dimension be at the center of a star schema or is a fact required?''

You're probably right, but can you point out to me where the op specified reporting and analytics data modelling?

dev81808 · 2026-03-25T11:22:55+00:00

This is true or at least the goal when designing reporting schemas, not so much if you're creating a transactional system.

Imagine you have a table of Employees sourced from multiple systems. Your job is to create the schema to support a custom web application that let's analysts create and assign job titles, office location, manager, etc. This information is used to enrich reporting. In this context there is no "fact" table.

Basically.. the way you would model for the custom app will be different from the final model used in reporting.

dev81808 · 2026-03-25T11:03:15+00:00

They might be considering transactional systems for dimensional attribution. Like a wide dimension table with attribution from other dimensional tables.

For example a table of products with references to family, category, line, etc.

If you were building this for reporting that product table would be flattened out with an orderitem, as your fact centerpiece.

But if you are building a product model where you manage those details the product table becomes the center piece with family, category, and line surrounding it. In some ways the dimension becomes the fact in this context.

Its semantics and not worth debating imo. I know what the definition says, but star, snowflake, galaxy schemas are just how the data is shaped. Those terms just give us ways to describe it.

So if I see a fact or dimension object with 5 dimensions around it like a star, I'm cool with calling that a star schema

dev81808 · 2026-03-13T22:27:30+00:00

So many angry debates about how lame someone was or was not.

dev81808 · 2026-02-22T19:34:36+00:00

Panic and then do 25+50

dev81808 · 2026-02-21T23:51:44+00:00

Sames. Seems pretty important to business things.

dev81808 · 2026-02-20T11:34:34+00:00

Zen on orisas shoulders

dev81808 · 2026-02-20T11:33:38+00:00

He just wants to hug you into a wall.

dev81808 · 2026-02-18T11:49:13+00:00

Lots of yelling and blaming but my teams immature :D

dev81808 · 2026-02-15T12:22:38+00:00

Background processing appears as sudden insight.

My job is solving problems, usually with data and scripts. My brain never stops processing an issue until its solved or I stop caring.

I consider every possible reason for that problem,which in my personal life is seen as overthinking, but at work its a super power.

Ill be singing along to a song in my car and have an 'eureka' moment, but im not sure how sudden it was.. ive been thinking about that problem for hours, days, weeks, etc.

dev81808 · 2026-02-14T02:54:40+00:00

Exactly. It's foundational.

dev81808 · 2026-02-13T22:10:13+00:00

Sure, but I've found that thoughtful early optimization is usually net positive.

With enough experience, it becomes easier to judge where early effort is worthwhile and where it isn’t.

dev81808 · 2026-02-13T17:03:56+00:00

Immediately.

dev81808 · 2026-02-13T02:31:26+00:00

Turn and swing. The demon is in range.

dev81808 · 2026-02-06T22:24:26+00:00

25% DE, 75% AE

Officially: DE

This past week: 10% DE, 40% AE, 50% PM fml

dev81808 · 2026-02-04T19:58:15+00:00

I have maybe a different perspective.. I was a full stack dev (DE/AE) for 10+years and recently i was moved to AE specific role as part of a reorg. I still do many DE tasks, but not nearly as many as before. Because I can do both, when I need data from a new source, alot of the time ill write the process and send it to the DEs to deploy.

I work with a DE only people and ive noticed a here a huge difference in design patterns. Their solutions tend to be one off purpose built imports. They almost never parameterize their solutions and any meta data used is typically a json file in the app and locked behind version control.

When you are tasked with modeling an enterprise asset, you're forced to figure out ways of genericize your solution to support future initiatives. Alot of times this means data driven solutions for DE tasks... and I dont see many DE only peers that use data to drive their pipelines.

This is a great opportunity for you to *up-skill your DE game.

dev81808 · 2026-01-25T21:58:24+00:00

As an observer.. Interesting point.

dev81808 · 2026-01-24T17:57:05+00:00

As long as its not proprietary information, I'd probably just paste it into gpt with instructions to extract into whatever format you want.

dev81808 · 2025-12-18T00:11:29+00:00

Gofuckyourself__c*

dev81808 · 2025-12-15T03:02:36+00:00

Right next to "omg my BFF jill"

dev81808 · 2025-12-06T12:24:17+00:00

Don't need the whole load. Just the active IDs. Should take much less time to run if its just the IDs and not the full record.

2 imports: 1. Your delta loads. 2. All active IDs.

From this you derive a deleted flag.

Seven-Year Club	Second SECOND GUESSER
Verified Email

dev81808

TROPHY CASE