I can pay my taxes with a paper dollar bill.
That's not just shared acceptance because even if the mighty USD should crumble and fall, a US citizen will still be able to pay the taxman with a dollar bill which is in itself of great value.
26 karma · joined February 15, 2020
That's not just shared acceptance because even if the mighty USD should crumble and fall, a US citizen will still be able to pay the taxman with a dollar bill which is in itself of great value.
The amount of people asking if they can upgrade the CPU, GPU, SSD/HDD or memory in their new-ish laptops is disheartening. Most of the questions concerns the CPU og GPU where the answer is no 99.99% of the time these days. 90% of consumer grade laptops have the RAM soldered to the mainboard too now. Luckily the HDD/SSD is usually replaceable or upgradeable in case of failure, performance problems or lack of free disk space... but for how long?
From a purely ecological standpoint, the laptop producers should be forced to buy back and recycle all their shitty unupgradeable, unrepairable, made-to-fail consumer electronics. It's a shameful situation we are in.
If societies can get 99% of glas and plastic bottles recycled using bottle deposit money, we should be able to reach the same figures for consumer electronics like laptops.
E.g. using NATURAL JOINs covers about 1/3 of the use cases where students or apprentices are usually fiddling with INNER JOINs or joining relations using WHERE TableA.ID = TableB.ID, and it's syntax is much simpler.
With a well thought out schema, I personally find that NATURAL JOINs covers about 80% of my needs in that respect, and being unable to NATURAL JOIN tables is beginning to indicate well, not a "code smell" but what I would call a "schema smell".
I fully agree. Joining relations in a relational databases should absolutely be simple - and it absolutely can be:
SELECT col_x, col_y
FROM TableA
NATURAL JOIN TableBThe double M2-SSD and double 2.5" SATA for RAID is also great in such a tiny box.
I really hope a new BIOS will make it compatible with the Ryzen 4000 desktop APUs when they arrive later this year.
Everyhing is alerts and warnings when clicking the link.
But what if you are working in a municipality and need to be able select all commercial buildings with more than five stories, or businesses situated in the basement of the building for the yearly fire inspections? Then string-searching all those randomly entered address lines will quickly become a complete nightmare - where as if the floor number was normalized and stored in its own column the query for the fire inspector's report would be a piece of cake.
This is a good example of why it's so hard to do cookie-cutter-implementaion-ready-schema-design-templates. It's also a good example of why datamodeling is important no matter underlying tech-stack this data model is going to be implemented on.
Also, I prefer modeling the app, business or process in Chen's ERD first as I think it is much better at capturing modeling details than UML and other ERD-variants.
Also, just as each object class in OOP should do only one thing, each entity should be saved just one table. Eg. that "Employee" table in the first chapter of every beginner database book with a "Manager" relation as a foreign key to itself is an absolute catastrophe and very . The moment your CEO decides you are now in a matrix-organisation, everything breaks down datamodel-wise. The Employees go into one table, the Organisational Structure type into another - they are related by foreign keys and it's not that different from good OO modeling as people say. The tables containing organisational structure should probaly also have columns with a from- and to-date and a relationship to a Department table so different departments can be organised differently throughout their lifetime.
Also, entities which have some sort of lifecycle should also be split into different tables. So there should be a table for "Prospective Employees", "Current Employees", "Resigned Employees", "Former Employees", etc. An employee's day of resignation can now be not null and go into the right table. You can always UNION these three or four tables together into one big view or materialized table, and at the same time you will avoid a massive amount of WHERE statements that each need their own indexes, picking out just the right employees from that big generic Employee table in every effing query.
Also, columns with endless NULL values are a "code smell" in a relational database. Whatever value is hiding in the few rows with values probably belong to another entity and should have been stored in another table with the name of that "thing". Eg. the employee's day of resignation again.
Also, 99% of all business datamodels can be implemented in a relational database using just tables, views and queries created in standard SQL. You will rarely if ever need user defined functions, generators, connectors, stored procedures, foreign code blobs and other exotic and vendor specific extensions.
Also, I recommend reading everything by Joe Celko.
Salary disclosure is also a prerequisite for having a public discourse about equal pay and equal rights based on factual information. You might call that to: "gang up", but I certainly wouldn't.
Our daughters, girldfriends, mothers and sisters are all living breating people in our lives - maybe even the most important ones we have where as a company is just a thing. My own startups are just a piece of paper, a tax information number, an organizational construct, nothing more. I can create another one in 2-3 days. Close a company and if there's customer demand, another one will just spring to life and fill the gap. I might be sad and in debt for a while, but society at large will not even notice. It doesn't matter.