No, there was a period of time where I wouldn't use bookmarks and instead left open like 25 tabs that I would eventually get to. Things like programming articles, tutorials, interesting projects on github, etc.. Most of the time I never got to them and it would be like September in real life but the article I saved in a tab was dated in June.

I never broke the 1 row threshold but it got to the point where I couldn't read most tab names. Now I just tuck those things away in categorized bookmarks.

Currently I only keep tabs open for active things I'm doing or for services that I like to keep open because I check in on them through out the day.

Opera's feature of remembering your last session is/was nice though. I survived on that feature when I had lots of tabs open for weeks at a time.

Win7

Just wait until you look at your first JS-heavy webpage.

Firefox has a bunch of utilities that will make it run just as dependable and often times faster.

I'll pass on the comment about not using snoopware, but I guess it's too late for that now.

Apple got burned by Adobe and have been pretty serious about not being beholden to another company for applications, right or wrong their fear would be getting stuck with a crappy browser because the other company decided to stop supporting Apple.

Apple needs an HTML 5 rendering system they control. They need something they can bundle for developers to rely upon in MacOS and on iOS. So no matter what they're still going to have to invest in WebKit.

They could choose not to build a browser on top of that, sure. But relying on Google means relying on a competitor. It also means subjecting users to the quirks of Google's non-standard interfaces. That would never do.

Also it would mean losing the iCloud integration.

I just can't imagine how it would make sense to give all that up, just to save on building a UI around WebKit.

Pretty much the same reasons why Microsoft still ships IE (except more desktop, less cell in that case).

I actually think Microsoft going all in on Firefox and abandoning IE (for example) could be a strong strategic move for many reasons.

Yup. This also explains why MSIE on Mac OS and Safari on MS Windows are dead.

Lol, I do this. My bookmark menu is a mishmash of porn, programming articles, eclipse tutorials, and the occasional io9 article "I'll read later."

I recently got the idea to consider these kind of arguments applied to a hypothetical scenario where a customer walking into a store steps on a landmine in the parking lot.

"Well, the landmine was mentioned in the docs. You should have read them more carefully."
"The mine only explodes if you step in that exact spot. Experienced shoppers know not to step there."
"That parking lot is deprecated. Every Real Shopper knows you're supposed to use mysql_real_escape_parking_lot."

Lolled at mysql_real_parking_lot

I thought we were all supposed to use pdo_real_escape_parking_lot. Get with the program, man!

This conversation inspired me.

At work, I have a database set up and everyone is networked to it. I'm basically the only one who knows how to use it, but one of my coworkers seems to be getting into it pretty good. Every time I see his screen, he has it open and I noticed a few extra tables and views in it. In general, I have a few scripts that I give to my coworkers and they just copy/paste them into the query windows and press Run.

He decided to go ahead and back up our sales history (we have to do this because the program that we pay for doesn't have persistent sales history, but I'll save that rant for another day). Basically, the query script I gave him to run cleans up the data and converts into line-item form, which takes 3 tables and 125 LOC (I know, I should use processing language or triggers, but whatever). I told him to always be careful whether working with the sales history or anything really, by backing up the files to .csv, taking the time to run the queries to be sure they reflect what he wanted, and being very very sure and careful that the outputs align perfectly before running updates, deletions, or anything else.

I brought him over to my computer and taught him about transactions, showed him how the database never changes until "commit;" is ran, how that database defaults to transactional, and the whole enchilada. I know, I'm an evil bastard for making him sweat for 2 months, but I did want to enforce the idea of being careful and be sure he understood that data is sacred.

Hopefully my newb database modeling questions havent driven anyone nuts yet BUT...

In MySQL, I have a PROJECT table and a PARTNER table. Each PROJECT can have many PARTNERS, and each PARTNER can belong to many PROJECTS. So many-to-many, and I created an association table which I believe is standard. My teammate also wants to have PARTNERS that are NOT assigned to any PROJECT.

So is this just as simple as creating a PARTNER and not having it exist in the association table? That feels dangerously close to an orphan record to me, but I could just be overthinking it. If its bad design, can anyone outline the main problem? Id like to get further than just having some notion something is bad, and actually understand the why.

???

Its easy to do, Im just wondering if theres anything wrong with the design. Also whats the advantage to putting the partner in the assoc table at all if its not associated to anything?

I agree with you there, actually. Fundamentally, what you are asking if is okay to do something like this, I think:

I'd prefer it this way, tbh.

The problem with my first answer is the following:

Then the following query is wrong because you did insert instead of update (which is far more expensive than the not exists query or a join, I think):

Since your intention is to see if partners exists without a project. There is a project associated with this partner, but you don't know that for certain now.

Also to add, you can now place foreign constraints on both projects and partners from the partner_project table, so you have better referencial integrity.

Certainly worth the trade-off, IMO.

I think there is no advantage and its pretty bad design (looks like Dave agrees). But nothing whatsoever wrong with having partners in the Partners table who don't appear in the ProjectsPartners table.

So no mention of it in here yet - the other day Epic released their new Unreal Engine 4, with somewhat radical changes in licensing policy. Instead of $millions It's now $19/month and includes full source code access on GitHub. I have to admit, really quite tempting to buy one month just to check it out - though my computer is likely far too underpowered to run it properly. You needn't keep up the sub to keep using it, only for further updates. They also want 5% of gross if you ever release a product from it.

Yes, this is what you do. It's not an orphan record since you actually have that partner.

You wouldn't put them in the association table because they don't have an association.

All of this sort of depends on your context.

Ideally, you'd have a single place that creates partners. Even if you have lots of user facing places where partners can be created, its should all boil down to one spot in the code. Partners will probably have a bunch of metadata like "name, address, contact info, ..." and so centralizing creation means you don't need to do the same thing in a bunch of places. And this information could all be useful for different features that have nothing to do with what projects someone is associated with.

Now when you're making associations between projects/partners you can assume that all of your partners already exist (still check, and if its missing redirect user to a creation place or just throw an error and so you're aware of the bug).

You wouldn't put the partner in the association table if they don't have an association.

On another note, this is where I generally advocate for never deleting/updating your core data. So my association table would probably have create date and delete date columns. When I create an association I'd leave delete date null and have my client logic look at that when querying. When I 'delete' an association I'd just set the delete date.

Again, it depends a bit on your use case since an approach like this makes your other logic more complex. But if you have a good architecture that keeps all data access to one spot its not bad at all.

Thanks guys! Sounds like I'm just paranoid too much and should just shut up and code.

I too don't like deleting data and have soft deleting already implemented!

Nice.

I've had long back and forth discussions on whether or not it's a good idea to have null references. I'm not convinced it's always bad but you need a really really good reason to use them because you can usually talk yourself out of it, for example imagine this situation:

You have leads.
You have salesmen.
A salesman owns a lead.

What happens when a salesman who has 150 leads gets fired?

Do you delete him from your system, but then do you also delete all related leads because they are associated to him?

Do you instead do some type of bulk operation on salesman-delete in which all the leads automatically get set to a null reference?

Or maybe you set them to a place holder object (like "unassociated") so you can keep track when the change was made, etc.?

Maybe you offer a manual option where after that delete routine finishes you can move all of the unassociated leads to someone else?

Do you never delete him and set a fired_at date field to the time of termination? (I like this solution the best), but now you have 150 orphan leads who are associated to someone who no longer works there so it still requires manual intervention to move the leads to someone who is still a salesman.

All those options are possibilities and there are many more.
Eg, you could have a SystemSalesman who get all the leads transferred to him, and then figure out how to redistribute them later.
This is a business question and really has nothing to do with NULL references or even your database. The way you've posed the question suggests you are letting your persistence mechanism drive the way you think about the business, which you shouldn't be doing.