Readit NewsI'm wondering why anyone would want to use anything else at this point (for SQL).
If I'm understanding you right, you're suggesting the author thinks that researchers are intentionally doing poor constructions to undermine public perception of classical art as part of some sort of culture war? I don't see anything in the article to suggest this
By claiming our ancient predecessors had terrible taste you can make them look like primitive fools, and make our own modernity appear superior in comparison.
When boiled down to culture war brainrot the poor coloring in the reconstructions becomes a woke statement that the brutish patriarchal empires of antiquity have nothing to teach our sophisticated modern selves and that new is good and old is bad. A progressive hit-piece on muh heritage.
Anything you don’t like is a purple haired marxist if you squint hard enough.
Idk why my brain went there. I’m guessing the years of daily exposure to engagement-farming ragebait had something to do with it.
Can’t really justify it at work though, projects are too big to and gnarly keep in my head.
6. ensure there are no nulls in firstname and lastname
7. alter the columns to be NOT NULL
Of course, some dbs (SQLServer?) infer NULL from the empty string, or am I misremembering?
Always having the columns be NOT NULL is a fundamental cheat, after always having a PK, or is that too old school for 2025?
Say I have a users table with a name column. Then I alter the table and split the name column into two new columns: first name and last name.
How is it possible to infer this change, just from seeing the new and old columns?
1. Migration that adds firstname and lastname columns will all nulls
2. Deploy application code change to start populating firstname and lastname alongside fullname, still reading fullname in the code.
3. backfill the firstname and lastname values with a script/command/migration
4. change app code to read firstname and lastname and stop writing fullname
5. drop the fullname column
What does your testing strategy look like with bigquery? We use snowflake, but the only way to iterate and develop is using snowflake itself, which is so painful as to impact the set of features that we have the stomach to build.
My current headache is what to do with an actually big table, 25 billion rows of json, for development. It’s going to be some DBT hacks I think.
God help you if you want to unit test application code that relies on bigquery. I’m sure there are ways but I doubt they don’t hurt a lot.