Main Area and Open Discussion > Living Room

Technology Myths

<< < (5/10) > >>

Deozaan:
Myth: Full hard drive means a sluggish computer.

While this can lead to some slowdown with the HDD having to seek everywhere from fragmented files, the real problem is most likely that that the hard drive is full because you've installed a billion programs, all of which are running services which are usually visible from a glance at the tray.

Pseudo-Myth: More memory will make your computer faster.

This is true (or can be), but many people think a bigger hard drive is more memory.

Deozaan:
Oh, and the myth perpetrated by Dell that pink or yellow computers are cool.  They are not.  They just aren't.  Sorry.
-Ralf Maximus (November 07, 2007, 10:01 AM)
--- End quote ---

I've never seen a pink or yellow Dell, and I used to work there.  :-\

Ralf Maximus:
Ahem.  It appears in your absence they were unable to resist the... erm, not-so-dark side.

Deozaan:
Ahem.  It appears in your absence they were unable to resist the... erm, not-so-dark side.
-Ralf Maximus (November 07, 2007, 06:28 PM)
--- End quote ---

I guess I was the only thing keeping them straight...  :P

f0dder:
imho you need some database layer abstraction, at least you certainly don't want to sprinkle your code with SQL strings all over.-f0dder (November 06, 2007, 05:29 PM)
--- End quote ---
Of course I want a (one, singular) data abstraction layer. But I don't know why I would want a second one so that I'd have the opportunity (say) rephrase all of my stored proc calls to work through Oracle.
-CWuestefeld (November 06, 2007, 06:19 PM)
--- End quote ---
My database needs have always been pretty simple, so I've never worked with stored procedures - syntax of those are probably different from db to db, but invoking them pretty similar?


I don't think so. I know the target is SQL Server, and I have another SQL Server available to me for development; why in the world would I want to develop against something different, and risk getting to production only discover we'd made a mistake?
-CWuestefeld (November 06, 2007, 06:19 PM)
--- End quote ---
Obviously depends on what you're doing - for a big and complex project, it's not feasible switching to a different db provider (banking software, anyone? :)), for smaller systems it can be nice being able to demo features on a laptop that doesn't have a network connection.

Supporting multiple database backends is, again, probably not something you want for complex systems, but for simpler stuff (web community, blog, simple shopping system, and things of similar scale) it's nice enough if you can just plug it into whatever's available.


BTW, I definitely don't want SQL strings all over. In fact, my rule is NO SQL strings anywhere -- everything goes through a stored proc (although I haven't quite figured out how to square this with LINQ, if indeed I decide to use it).
-CWuestefeld (November 06, 2007, 06:19 PM)
--- End quote ---
Haven't tried using LINQ, but the snippets I've seen look pretty nice compared to spaghetti SQL strings... good enough that I probably wouldn't mind using it. And I guess it's a bit more portable than stored procedures? :)

But I guess stored procedures are run on the db server, and can thus have some efficiency benefits compared to pulling data out of the db and processing client-side...

Navigation

[0] Message Index

[#] Next page

[*] Previous page