Meaningful Keys

[boomzilla]

@Nelle said:

in these cases you can not use database traffic as a measurement or when you do, you have to weight it with an "importance" factor.

for example, when a busy worker bees hit the database 20000 times and everything goes snappy, and the queen bee hits the database only once and has to wait 5 seconds for its data, you'll still get to hear how "horribly slow" the application is and your own queen bee is going to order you to "fix" it.

Indeed. Real Life Profiling.

[boomzilla]

@blakeyrat said:

So grow a fucking spine and explain to your queen bee that she's an idiot.

That always works out well.

[blakeyrat]

@boomzilla said:

@blakeyrat said:

So grow a fucking spine and explain to your queen bee that she's an idiot.

That always works out well.

The point isn't "yell and bitch at your boss", the point is "create a case to explain to her that performance for actual users of the application is more important than performance for reporting, and thus you've optimized for it." Include facts and figures. Don't be a dick. Unless you have a really cool boss.

You can explain to someone that they're being an idiot without calling them an idiot. And if you can't, you should learn how: that's a thousand times more valuable a skill to have than any programming language.

[boomzilla]

@blakeyrat said:

The point isn't "yell and bitch at your boss", the point is "create a case to explain to her that performance for actual users of the application is more important than performance for reporting, and thus you've optimized for it." Include facts and figures. Don't be a dick. Unless you have a really cool boss.

I agree that you should at least try this sort of approach, which has only a passing resemblance to, "explain...that she's an idiot." Of course, from the description, it really sounds like that wouldn't make much of a dent in this case. It's also somewhat difficult to analyze, since we don't know how extensive the changes were, and how they affected the rest of the users. Or how important it was for the managers to see the data (though this is certainly inflated).

@blakeyrat said:

You can explain to someone that they're being an idiot without calling them an idiot. And if you can't, you should learn how: that's a thousand times more valuable a skill to have than any programming language.

I certainly agree with this, independent of anything else in this thread. Good communication skills are always a good investment, no matter what your job is.

[serguey123]

@blakeyrat said:

@boomzilla said:

@blakeyrat said:

So grow a fucking spine and explain to your queen bee that she's an idiot.

That always works out well.

The point isn't "yell and bitch at your boss", the point is "create a case to explain to her that performance for actual users of the application is more important than performance for reporting, and thus you've optimized for it." Include facts and figures. Don't be a dick. Unless you have a really cool boss.

You can explain to someone that they're being an idiot without calling them an idiot. And if you can't, you should learn how: that's a thousand times more valuable a skill to have than any programming language.

Please do tell where to find this invaluable resource, a lot of people will benefit from this.

"How to let an idiot know he/she/it is being an idiot without offending him/her/it for dummies"

[blakeyrat]

@boomzilla said:

I agree that you should at least try this sort of approach, which has only a passing resemblance to, "explain...that she's an idiot."

Well, you have to remember that about 5% of what I type is actual advice, and about 95% is either trolling or lulz.

@serguey123 said:

Please do tell where to find this invaluable resource, a lot of people will benefit from this.

"How to let an idiot know he/she/it is being an idiot without offending him/her/it for dummies"

I just use trial and error. Start with, "fuck you're a dumbshit!" and if the reaction isn't positive, try lightening it up next time.

[Dorus]

@Nelle said:

i've worked on projects where databases were in 3NF, all indexes were optimised for the executing queries, tables partitioned, servers top-notch, and still we had to resort to denormalisation in order to create reports for managers who want to see EVERY FIELD from EVERY database on ONE BLOODY SCREEN. (and preferably formatted as a spreadsheet, but NOT exported to Excel, because then it is not REAL TIME, although they would be happiest if we would connect the Excel to the database, which I know is possible by the way, but please don't tell THEM that)
and judging from some stories, this is not at all uncommon ...

Glad to hear the managers are the most important users of the database, and they need to be updated on the ms. Too bad the end users will be delayed a bit more, especially with all the counting going on in the background by the manager display. This means the end users will be delayed in there action, most likely also delaying the report again. Not to mention you can't have to many users running around at the same time, those pesky guys only slow down the database.

 

Are you bankrupt yet?

[Lorne Kates]

@boomzilla said:

@blakeyrat said:

So grow a fucking spine and explain to your queen bee that she's an idiot.

That always works out well.

 

Except that bees are invertebrates and don't understand sarcasm

[serguey123]

@Dorus said:

Glad to hear the managers are the most important users of the database, and they need to be updated on the ms. Too bad the end users will be delayed a bit more, especially with all the counting going on in the background by the manager display. This means the end users will be delayed in there action, most likely also delaying the report again. Not to mention you can't have to many users running around at the same time, those pesky guys only slow down the database.

You were going fine until you tried sarcasm, this is how the shit works.  If you think this doesn't happens a lot you are in for a surprise

 

[Sutherlands]

As long as the database keys that have no meaning outside the database don't get outside the database... *wishful thinking*

[blakeyrat]

@Sutherlands said:

As long as the database keys that have no meaning outside the database don't get outside the database... wishful thinking

In wallet-sized card form!

[Jaime]

@Sutherlands said:

As long as the database keys that have no meaning outside the database don't get outside the database... *wishful thinking*

Use GUIDs for surrogate keys.  That tends to stop the use outside of technical scenarios.

 

... bracing for GUID religious war ...

[Sutherlands]

Well, in this specific scenario, the customer doesn't even know about the stuff I'm talking about... but things such as "Event" "EventAttribute" etc have both a Guid and an Id...

[Lorne Kates]

@Jaime said:

... bracing for GUID religious war ...

 

Identity them all, let GUID sort them out.

[Dorus]

@Jaime said:

@Sutherlands said:

As long as the database keys that have no meaning outside the database don't get outside the database... *wishful thinking*

Use GUIDs for surrogate keys.  That tends to stop the use outside of technical scenarios.

We once used GUID to make sure user's coulnd't guess the ID of the next img in our image service. Oops.

 @Jaime said:

... bracing for GUID religious war ...

 Oh, but i love GUID, other then identity fields, a GUID is unique in space and time. You can do fun things with that :D

 

[boomzilla]

@Dorus said:

We once used GUID to make sure user's coulnd't guess the ID of the next img in our image service. Oops.

Well, there's your problem Should have used UUIDs.

[zzo38]

@Serpentes said:

Calculating Easter programmatically is insane.  If you need to track Easter, you really just are going to have to store a list of Easter dates in a table somewhere...

Actually I have used the Zeller's Card method and it works and is relatively simple. I implemented that method in TeX.

[boomzilla]

@zzo38 said:

Actually I have used the Zeller's Card method and it works and is relatively simple. I implemented that method in TeX.

Psaw! Here's my Whitespace implementation (also copied into the tags for good measure):

[dhromed]

@boomzilla said:

@zzo38 said:

Actually I have used the Zeller's Card method and it works and is relatively simple. I implemented that method in TeX.

Psaw! Here's my Whitespace implementation (also copied into the tags for good measure):

 

That's pretty cool.

[havokk]

@Dorus said:

 Using non-meaningful keys, like ID fields is always wrong. A database contains data about reality and a ID field never matches with something real.

Beside, ID fields hurt performance, to get your data you need to do a join, this is always more expensive then have the date stored in the right table directly.

 

I disagree with your use of "always". Whether id fields hurt performance or not depends on the database product you are using. Denormalisation is per-product - a denormalisation step that makes sense in Microsoft SQL Server does not necessarily make sense in Oracle Database. Additionally, OLTP and OLAP databases are different again.

Besides, sometimes there is no natural key. For example, what natural key would you choose to uniquely identify a person?

@Dorus said:

This is what's meant with the 3NF "Every non-prime attribute is non-transitively dependent on every candidate key in the table." Every sane database design should comply to that.

 

Again, I disagree. If denormalisation  is required by a system then that system, by definition, will not be in 3NF (or BCNF or whatever you were at).

[Dorus]

@havokk said:

I disagree with your use of "always". Whether id fields hurt performance or not depends on the database product you are using. Denormalisation is per-product - a denormalisation step that makes sense in Microsoft SQL Server does not necessarily make sense in Oracle Database. Additionally, OLTP and OLAP databases are different again.

Like i said before, with denormalization you might optimize for one action, but lose other ground (more work for constraints, or less contraints checked, read performance better, but write performance worse etc.) When you design your database your first goal should always be normalization. And last time i ran a benchmark to see if denormalization was worth it, i saw it rarely was. You need like 1:1000 reads vs writes, and even then the difference is VERY small, compared to a lot more work to hang onto your business rules. Ofcoure the small difference can mean a lot when a read action happens extremely often, but it's not a very usual situation. Also make that benchmark! More often then not the results will surprise you (this is true for any form of performance optimization, benchmark or it doesn't count!). I agree with you some database systems can gain more from certain techniques then others. Also, even a normalized database allows many different solutions that are all normalized, but offer a great variate in performance.@havokk said:

Besides, sometimes there is no natural key. For example, what natural key would you choose to uniquely identify a person?

 As for ID fields (i don't remember normalization dictates the use or non-use of ID fields and the like), you should read this page about surrogate PK and substitute PK he makes a number of valid points.

 

• There is at least one candidate key (before the surrogate is added),

<p class="bodyind">• the table is a parent in at least one association, and</p>

<p class="bodyind">• there is no candidate key small enough for its values to
   be copied many times into the child table.</blockquote></p><p class="bodyind">I would like to add to that that substitute keys and surrogate keys should always be avoided, if no other solution is present, give your surrogate keys a real world meaning (like customer number printed on letters to the customer) so they become a substitute key instead.</p><p class="bodyind">As for what i use for a person. It strongly depend on the domain. For a webshop, username is fairly unique. For the hospital administration, you are going to have to discuss this with the <span id="result_box" class="short_text" lang="en"><span title="Klik voor alternatieve vertalingen" class="hps">domain</span> <span title="Klik voor alternatieve vertalingen" class="hps">expert, you can't get away with using a new unique number for every patient, you also need something that matches real patients with the rows in your database. Most likely the hospitals has a procedure how they identify patients. Anyway, you can't decide for yourself what's unique in this. The domain expert has to give you that information, and once established you make that information unique in your database.</span></span> Odds are high a substitute key is already present in the form of a patient number or anything the like. Notice this shouldn't be a ID field (by default), but something the domain expert agrees with. You are going to see this number a lot in the hospital, probably on many forms. Perhaps he wants it to start with a p, (p1234) or patient numbers should be unique across different hospitals nearby so patient data can be exchanged easily (even when they use a different database)</p><p class="bodyind">Using identity fields yields many different problems too, like, after a insert in 1 table, you need to do a lookup before you know what number to use in the next table. Not to mention what happens when you need to import multiple lines at the same time. Using a self made number is much easier then a identity field in that case. (I'm talking about sql server now, trough i'm pretty sure identity fields work the same in other databases). </p><p>@havokk said:<blockquote>Again, I disagree. If denormalisation&nbsp; is required by a system then that system, by definition, will not be in 3NF (or BCNF or whatever you were at).</blockquote></p><p>What crazy requirements do you use that dictate implementation details? As far as i know requirements and implantations details are completely separate. There is nothing normalization forbid you to do in a database, other then dictate good practice. This is like saying the requirements forbid you to use code standards or unit testing. </p><p>&nbsp;</p><p>@blakeyrat said:<blockquote>What is this magical database system you're 

using where joins affect performance? Joins only slow you down if:

1) Your PKs are ridiculously huge (first_name, last_name, DOB, user_name)

2) You're joining in tables that are irrelevant to the query
(joining in "car_owned", then never referring to it in another clause)

Have you actually benchmarked any of this, or are you just echoing some bearded Unix geek who was an expert in OS/400 databases in 1986, and just assuming that's still relevant?

 

Using user_name alone should be more then enough as a PK. I'm not sure if this is the second or 3th NF, but one of those dictate shortest possible PK's. Also, as long as first_name column hold a fair amount of unique values, a join won't be slowed down by the other 3 fields.If it is the same 90% of the time, you better switch the order of columns in the PK so that another one that has a higher level of uniqueness comes first. As soon as the first column only result in 1 unique value, the database won't look at the other 3.

BTW, if user_name is not unique i'de like to see the login form of your website:

Username*:

First name*:

Last name*:

DOB*:

Password*:

 *Required.

 And yes, i benchmark my stuff before i make claims about performance. I've never seen a join that was faster then looking up another column in the same table.

@blakeyrat said:

EDIT: this thread is ridockulous. Is it just full of trolls? I'm starting to think so.

Been wondering if you where trolling me too, i decided i should just make fun of the ridiculous argument, and reply serious to the serious one's.

 @boomzilla said:

I'm generally interested in some balance of write and read performance, depending on the circumstances. If all you need is just that simple reference value, then I guess your comment makes sense. But assuming you need anything else (which is probably pretty often--at least it is for me), you're going to have to do the join anyways. Also, what could / should be updating a single column in a single row can suddenly balloon into updating thousands or millions of other rows. Not to mention all of the locks that would create. I don't hate my users that much (yet).

You would be surprised how often you do not need that additional data. Also, if you are going to have to join anyway, that id fields add 1 more field the database has to retrieve and load into memory. As long as your natural key does not contain any ridiculous dataset like 90% of the time only the last 4 chars of a 450 char string differ, a join on a id field isn't going to be much faster then a join on a string field. I've seen plenty of times a join the string field was in fact faster.

Even when you do have that ridiculous dataset where only the last 4 chars differ (I've seen them), my solution was to add a calculated column that had the data of the first column backwards. Next i included that backwards column into my index. (Wasn't a PK index, but could have been).

@boomzilla said:

You're all over the place here. I guess it's possible that you deal with situations where the reference key is all that you need. Then yeah, I guess I can understand how the performance would be better for you. But if you need that data, then you need that data. Sometimes you need further joins, too, in order to wade through the hierarchy of objects / tables / data / whatever. My point is that in this case, you've probably made the DB use a lot more data in its indices (due to composite keys vs a simple key), which also means it has to look at more information to do the join.

And an ON CASCADE UPDATE is not a magical device. If you don't see the performance implications of that, you're not paying attention.

 I don't see why the DB uses more data in my case, i got 1 ID field less to worry about, also, columns not included in the select are offten not even read by the database engine.

I do agree ON CASCADE UPDATE is not magic. It has it's disadvantages, but you won't run into them in most general usecases. Don't confuse it with ON CASCADE DELETE,  that one more often then not results in entire databases running empty on 1 deleted row, and are not considered very safe to implement in most situations.

ON CASCADE UPDATE only hits tables that have a FK directly to the current table (or indirectly trough a composite key). You won't have that many rows that are referred my thousands or others. The fact alone that those other row that refer to the first one will not have many references them self, means that at best 0.1% of your dataset has this characteristic. For that 0.1% to also be changing daily is unlikely. If you do need to optimize for that case, i prefer to either look for a alternate PK, or put changes to this table in a queue and handle them at night. This might be a acceptable solution if you use company_name to identify your customers, and sometimes company's change there name. You don't want to put your database on hold for 15 mins during the day when one of them does this, but it's perfectly acceptable to run a queue like that at night.

 

@Jaime said:

@Dorus said:

As for performance, the more data you put in 1 table, the less joins you need. Thuss more performance. This is especially nice if you remember normalization just allowed you to put more data in one single table.

Head asplode.

Normalization almost never creates more columns, it almost always pushes data out to other tables.  You aren't talking about the benefits of normalization, you are talking about the benefits of natural keys.  The debate between intelligent and surrogate keys is far from over and far from one-sided.  I don't have a problem with intelligent keys when they are appropriate, but I do have a problem with your insistence that surrogate keys are never the answer.  Your arguments also reek of premature optimization.

 

I think this happens somewhere around the 4th - 7th normal form, but the goal of those is to have less tables. There are normalization techniques that pushes data back into tables. One of these techniques is to use natural keys. Another one is that you can sometimes eliminate a table when the data it contains can already be found in another because it has a 1-1 or many-1 relation.

Imagine a class only exists when it has at least 1 student. All students have 1 class. Also teachers are assigned to multiple classes. It's perfectly acceptable to make this scheme:

Teacher		Teaches			Student
FK1	<-	FK1	FK2	->	FK2
Name		Teacher	Class		Class	Name
PK		pk	pk			pk

 

No need for a table class, since "Select distinct Class from Student" retrieves this already.

 

Edit: I looked up my book. They denormalize at the end of the process, to make  queries simpler and spare out joins. Notice this is at the END of the process, around the time where you can decide if adding additional constraints cost less then less tables. denormalizated tables should still be closely guarded by constraints so no bogus data makes it in.

[boomzilla]

@Dorus said:

You would be surprised how often you do not need that additional data.

Actually, I think you would be amazed at how often I do need that data.

@Dorus said:

I don't see why the DB uses more data in my case, i got 1 ID field less to worry about, also, columns not included in the select are offten not even read by the database engine.

Well, firstly, I was talking a lot about tables where you have composite keys. So all of your FKs are likely to be bigger. That's what I was talking about.

@Dorus said:

I do agree ON CASCADE UPDATE is not magic. It has it's disadvantages, but you won't run into them in most general usecases. Don't confuse it with ON CASCADE DELETE,  that one more often then not results in entire databases running empty on 1 deleted row, and are not considered very safe to implement in most situations.

ON CASCADE UPDATE only hits tables that have a FK directly to the current table (or indirectly trough a composite key). You won't have that many rows that are referred my thousands or others.

Yes, in fact, I do. Of course, this is one of those with a giant YMMV, but I can assure you that this is not as rare as you seem to believe.

[Jaime]

@Dorus said:

Using identity fields yields many different problems too, like, after a insert in 1 table, you need to do a lookup before you know what number to use in the next table. Not to mention what happens when you need to import multiple lines at the same time. Using a self made number is much easier then a identity field in that case. (I'm talking about sql server now, trough i'm pretty sure identity fields work the same in other databases).

You are asking us to take your advice on a much-discussed topic, but you don't even know the platform you are using very well. You don't have to query the table to find out the last identity value inserted. When I started using SQL Server in 1996, it had @@IDENTITY which works but has some subtle issues; those were fixed a long time ago with the SCOPE_IDENTITY function. I find it hard to believe that you have ever written a large scale application on SQL Server and you aren't aware of these.

[Jaime]

@Dorus said:

you should read this page about surrogate PK and substitute PK he makes a number of valid points.

...

Edit: I looked up my book. They denormalize at the end of the process, to make  queries simpler and spare out joins. Notice this is at the END of the process, around the time where you can decide if adding additional constraints cost less then less tables. denormalizated tables should still be closely guarded by constraints so no bogus data makes it in.

Are you basing all of your knowledge on one book? Not even a book written by someone respected in the industry, a book written by a career academic? At least you could have cited Joe Celko.

[Dorus]

@Jaime said:

You are asking us to take your advice on a much-discussed topic, but you don't even know the platform you are using very well. You don't have to query the table to find out the last identity value inserted. When I started using SQL Server in 1996, it had @@IDENTITY which works but has some subtle issues; those were fixed a long time ago with the SCOPE_IDENTITY function. I find it hard to believe that you have ever written a large scale application on SQL Server and you aren't aware of these.

Interesting. No, i did not know about SCOPE_IDENTITY, i'm a student and the only database application i worked on was for a small company and they did now know about SCOPE_IDENTITY. I do wonder if SCOPE_IDENTITY was available in the SQL Sever version they used at that time.I think they worked with 2005 at that time, but the code that used @@IDENTITY was written against 2000 i think.

  @Jaime said:

Are you basing all of your knowledge on one book? Not even a book written by someone respected in the industry, a book written by a career academic? At least you could have cited Joe Celko.

If you want to know my book, it's

"Volledig communicatiegeoriënteerde informatiemodellering FCO-IM" by Guido Bakema, Jan Pieter Zwart and Harm van der Lek. And i wasn't really citing it, more reading it any interpreting there opinions. It takes half a academic degree to read that book and understanding what they write (even trough it's very well written Dutch), with me quickly reading it on my free Sunday i need to be a bit carefull about what i claim they wrote :P

 

Edit: Found the book online. See page 157 (it's 171 in the dutch version).

[havokk]

Dorus, I suggest you pick up "SQL and Relational Basics" by Fabian Pascal, any of the "Pro SQL Server Database Design and Optimization" by Louis Davidson, and anything by Joe Celko, especially "SQL For Smarties".

I found the first two to be easy to read. Louis Davidson wrote an interesting book on a dry and boring topic. Mr Celko, well, he is Joe Celko, he doesn't make any allowances for people who aren't as smart as him (and he is very smart). Be prepared for his books to educate you and [piss you off in equal measure.

 

[Jaime]

@Dorus said:

@Jaime said:

You are asking us to take your advice on a much-discussed topic, but you don't even know the platform you are using very well. You don't have to query the table to find out the last identity value inserted. When I started using SQL Server in 1996, it had @@IDENTITY which works but has some subtle issues; those were fixed a long time ago with the SCOPE_IDENTITY function. I find it hard to believe that you have ever written a large scale application on SQL Server and you aren't aware of these.

Interesting. No, i did not know about SCOPE_IDENTITY, i'm a student and the only database application i worked on was for a small company and they did now know about SCOPE_IDENTITY. I do wonder if SCOPE_IDENTITY was available in the SQL Sever version they used at that time.I think they worked with 2005 at that time, but the code that used @@IDENTITY was written against 2000 i think.

SCOPE_IDENTITY was added in SQL 2000. Doc reference here. That would make it at least six years old if SQL 2005 was out. @@IDENTITY worked fine as long as you didn't use triggers or merge replication and it's been around as long as identity has.


Care to reconcile these two statements:

@Dorus said:

Using identity fields yields many different problems too, like, after a insert in 1 table, you need to do a lookup before you know what number to use in the next table.

@Dorus said:

...but the code that used @@IDENTITY was written against 2000 i think.

If the code used @@IDENTITY, why the statement that you need to look up the identity value?


You also made this statement in the same post the identity quote comes from:@Dorus said:

Not to mention what happens when you need to import multiple lines at the same time.

This use case is so rare that SQL Server didn't even have the syntax to support it until SQL 2008.

[Scarlet_Manuka]

@Dorus said:

Using user_name alone should be more then enough as a PK. I'm not sure if this is the second or 3th NF, but one of those dictate shortest possible PK's. Also, as long as first_name column hold a fair amount of unique values, a join won't be slowed down by the other 3 fields.If it is the same 90% of the time, you better switch the order of columns in the PK so that another one that has a higher level of uniqueness comes first. As soon as the first column only result in 1 unique value, the database won't look at the other 3.

I begin to see where at least part of the confusion is coming from. You only have one use case in mind primarily, the one where every person in your database has a login into your system. And yes, in that case the username is a unique key and a reasonable candidate for a primary key (though this still means that username changes will be more costly than otherwise, if you allow them of course). But that's far from the only use case in existence. In my company, our primary database has around 1-2 million contact records, but only a few thousand people are set up as users. (Our customers have access to our database; they enter their client records into it.) It's up to our customers to know whether the clients they're dealing with are already in their client list or not. If the same client deals with more than one of our customers they will have separate records in our system (required due to privacy laws).

Even within the relatively small group of our few thousand customers, we've had cases where there are two people with the same name, working for the same company (and thus with the same contact details, because many of our customer companies have centralised contact details - all contact goes through an admin employee).

The other issue is whether you want to allow partial records or not. We require first and last name to be entered and that's about it. That allows our customers to fill out a sketchy client record to start with (enough to be barely useful) and fill it in later. For instance, if someone phones them up with an enquiry they can start a basic contact record and update it later if the client comes in for a consultation.

I've never seen a join that was faster then looking up another column in the same table.

Rare, but not impossibly so. If you want four columns and three of them are in a composite index on table A, it may be faster to get the fourth column from a join than from another column on table A, because you can use an index scan on table A and not have to look up the row at all. Obviously this depends on things like the width of table A, the size of the joined table, etc.

[belgariontheking]

@Serpentes said:

@locallunatic said:

@Jaime said:

You can calculate holidays?  Easter is possible, but too messy to even think about attempting.  Things like Christmas and the Fourth of July are always the same calendar date, but the business holidays associated with them change, sometimes on a whim.

 

Of course you can, and with business holidays you just need to check if the holiday lands on Saturday (so it's Friday off) or on Sunday (so it's Monday off).

 

Calculating Easter programmatically is insane.  If you need to track Easter, you really just are going to have to store a list of Easter dates in a table somewhere.  The simplified version of Easter date selection ("first Sunday after first full moon after March 21") is inadequate, because the real moon has nothing to do with it.  Instead, there are a series of tables and corrections that determine the placement of easter.  The process, called computus, is staggeringly complex, especially if you need to compute Easter for arbitrary years that may be some time in the past or future, as there are two cyclical corrections (the "solar equation" and "lunar equation") that also factor into the cycle and can and do cancel out.  Furthermore, there are a number of "special corrections" to fix problems in the tables; the most recent of these moved the date of Easter for the Catholic Church in 1690.  In all, the process of determining the date of Easter IS a repeating cycle ... one that repeats every 5,700,000 years.  Although well before 5.7My has passed, changes to the length of the year, lunar month, and day will break the current system.  Also, receiving a request to write holiday-tracking code robust over several million years would be an immediate sign that new employment is necessary.

I want all of your jobs.  Since it's necessary to know when Easter is, you must get it off.  I never get it off since it's on a Sund--- oh wait never mind.

 

[locallunatic]

@belgariontheking said:

I want all of your jobs.  Since it's necessary to know when Easter is, you must get it off.  I never get it off since it's on a Sund--- oh wait never mind.

 

To be fair I work in medical billing (in the USA) so my experience varies a lot compared to everyone else, thus my confusion due to weird holidays (weird here anyway).

[PJH]

@belgariontheking said:

Since it's necessary to know when Easter is, you must get it off.  I never get it off since it's on a Sund--- oh wait never mind.

You don't work Fridays or Mondays either I take it?

[boomzilla]

@PJH said:

@belgariontheking said:

Since it's necessary to know when Easter is, you must get it off.  I never get it off since it's on a Sund--- oh wait never mind.

You don't work Fridays or Mondays either I take it?

Those are not commonly holidays of the sort that gets one out of work in the US. Good Friday is definitely celebrated religiously, though I can't recall ever hearing about "Easter Monday" prior to this thread. And your link confirms that, as I've never lived in any of the parts of the country mentioned as celebrating it.

[PJH]

@boomzilla said:

@PJH said:

@belgariontheking said:

Since it's necessary to know when Easter is, you must get it off.  I never get it off since it's on a Sund--- oh wait never mind.

You don't work Fridays or Mondays either I take it?

Those are not commonly holidays of the sort that gets one out of work in the US.

Ah. They're both bank holidays in the UK; most companies that aren't in the service industries have both off. Certainly most offices are shut those days.

[frits]

@blakeyrat said:

Then stop trying to fix people problems with technology.

Isn't that what we do?

[boomzilla]

@frits said:

@blakeyrat said:

Then stop trying to fix people problems with technology.

Isn't that what we do?

Mostly, we just argue about stupid stuff, but, yeah, whatever floats your boat.

[frits]

@boomzilla said:

@frits said:

@blakeyrat said:

Then stop trying to fix people problems with technology.

Isn't that what we do?

Mostly, we just argue about stupid stuff, but, yeah, whatever floats your boat.

I meant as a profession, not here on this message board.

[boomzilla]

@frits said:

@boomzilla said:

@frits said:

@blakeyrat said:

Then stop trying to fix people problems with technology.

Isn't that what we do?

Mostly, we just argue about stupid stuff, but, yeah, whatever floats your boat.

I meant as a profession, not here on this message board.

Me, too.

[dhromed]

@frits said:

@blakeyrat said:

Then stop trying to fix people problems with technology.

Isn't that what we do?

 

Every problem solvable by It is a people problem given that they're all man-made problems.

Now let's discuss my egregious stretching of the definition of the term  "people problem"

 

[frits]

@boomzilla said:

@frits said:

@boomzilla said:

@frits said:

@blakeyrat said:

Then stop trying to fix people problems with technology.

Isn't that what we do?

Mostly, we just argue about stupid stuff, but, yeah, whatever floats your boat.

I meant as a profession, not here on this message board.

Me, too.

I'm going to go ahead and give you a 10/10 for that response.

 

[blakeyrat]

@frits said:

@boomzilla said:

@frits said:

@blakeyrat said:

Then stop trying to fix people problems with technology.

Isn't that what we do?

Mostly, we just argue about stupid stuff, but, yeah, whatever floats your boat.

I meant as a profession, not here on this message board.

My point is that if someone has a psychological problem that would apply whether or not a computer was involved, that is a problem that can't be fixed with a computer. You could write all the code in the world, and it wouldn't address the actual issue: your manager sucks and doesn't listen to smart people under him. If he were managing a pit mine, and there wasn't a computer within 20 miles, the exact same problem would apply.

[Xyro]

@blakeyrat said:

My point is that if someone has a psychological problem that would apply whether or not a computer was involved, that is a problem that can't be fixed with a computer. You could write all the code in the world, and it wouldn't address the actual issue: your manager sucks and doesn't listen to smart people under him. If he were managing a pit mine, and there wasn't a computer within 20 miles, the exact same problem would apply.

While I believe that is true and sensible and I don't disagree... there is also something to be said with working with what you have. What do you have? A bad manager and super technology skills? Well, maybe we can work around the PHB, then...

Of course, this assumes you have no other resources, which I thiiiiink is never true. But nevertheless, dragging a problem into one's own domain of expertise in order to try to fix it is not a totally unreasonable strategy, and certainly better than doing nothing about it. And sometimes avoiding the symptoms of a problem is the best way to deal with the problem when you lack the skill to take it on directly, at least on some scopes.

[boomzilla]

@Xyro said:

While I believe that is true and sensible and I don't disagree... there is also something to be said with working with what you have. What do you have? A bad manager and super technology skills? Well, maybe we can work around the PHB, then...

Of course, this assumes you have no other resources, which I thiiiiink is never true. But nevertheless, dragging a problem into one's own domain of expertise in order to try to fix it is not a totally unreasonable strategy, and certainly better than doing nothing about it. And sometimes avoiding the symptoms of a problem is the best way to deal with the problem when you lack the skill to take it on directly, at least on some scopes.

Plus, occasionally, the PHB may have a point, even if you can't see it.

[Dorus]

On a professional level, I think it's professional to point out when problems can not be solver with technology, instead of beating your code in all kind of impossible shapes to come up with solutions that in the end have much more disadvantages then usefulness.

If you have the mindset that your manager/customer knows everything better and you should make whatever they ask sounds pretty amateurish to me. You are the professional, and you where hired to warn them about problems beforehand. They don't need to know anything about computers, if they did know everything, why did they need to hire you in the first place?

[boomzilla]

@Dorus said:

On a professional level, I think it's professional to point out when problems can not be solver with technology, instead of beating your code in all kind of impossible shapes to come up with solutions that in the end have much more disadvantages then usefulness.

This is a false choice. It's not always up to you. Yes, obviously, the professional thing to do is to voice concerns. But it's also to recognize that you won't always win out.

@Dorus said:

If you have the mindset that your manager/customer knows everything better and you should make whatever they ask sounds pretty amateurish to me. You are the professional, and you where hired to warn them about problems beforehand. They don't need to know anything about computers, if they did know everything, why did they need to hire you in the first place?

Has such a person ever been identified? The real danger is the other way around: thinking you know everything better than them. Real life usually turns out to be much messier, and even good faith efforts by competent people can end up with stuff featured on this site.

[Nelle]

@boomzilla said:

@Dorus said:

On a professional level, I think it's professional to point out when problems can not be solver with technology, instead of beating your code in all kind of impossible shapes to come up with solutions that in the end have much more disadvantages then usefulness.

This is a false choice. It's not always up to you. Yes, obviously, the professional thing to do is to voice concerns. But it's also to recognize that you won't always will never win out.

FTFY

[Dorus]

 @boomzilla said:

This is a false choice. It's not always up to you.

Depend, if you are asked to make something functional, then you should just explain why it's hard to make it that way. If you fail to explain that you either had the wrong arguments, or your boss might actualy have better ideas about it then you (if he accept the disadvantages, those disadvantages migth actualy be wortht the benefits). When it comes to cost vs benefits, your boss/customer will always be smarter then you.

 

If you are asked to implement technical requirements that you know won't work that way, or will work bad, I'll stick with it you're a amateur if you make it anyway. You should be able to come up with a better alternative solution, or make good arguments why it doesn't work.

[blakeyrat]

@Dorus said:

If you are asked to implement technical requirements that you know won't work that way, or will work bad, I'll stick with it you're a amateur if you make it anyway. You should be able to come up with a better alternative solution, or make good arguments why it doesn't work.

Which all goes back to communication skill being more important than programming skill. You're a hundred times more valuable to the company if you can explain to management in a productive fashion how the company can produce better products.

[Dorus]

That's what i said right?

 And yes, if you don't you have people problems :D

[blakeyrat]

@Dorus said:

That's what i said right?

Yes but I'm using my communication skills to repeat the point for emphasis! ... or something, I guess.

[Weng]

@havokk said:

Besides, sometimes there is no natural key. For example, what natural key would you choose to uniquely identify a person?

DNA sequence + birth order.