The Heap™ – Consultancy ©® - 2011-11-04

« first day (304 days earlier) ← previous day next day → last day (4569 days later) »

Mark Storey-Smith

11:15 AM

@gbn Ever encountered "Failed Virtual Allocate Bytes: FAIL_VIRTUAL_RESERVE" on a 64bit SQL Server?

nah

Mark Storey-Smith

I'm on Slava's blog that I think you gave me the link too a couple of weeks ago and currently lost! :)

Obviously a gap in my knowledge here, I didn't think VAS reservation was ever a problem on 64bit!

when i see this stuff, it means a badly configured server,

or -g swicth etc

or 3 million entries in an IN clause

or some muppet using sp_xml_prepare and consuming memory

etc etc

Mark Storey-Smith

This particular server tops the pile of crappy code as it happens

Mark Storey-Smith

11:47 AM

Panic over, its 32bit

1 hour later…

1:10 PM

@Nick I tried having this convo with the boss regarding the database for our intranet site. We already have the SQL Server machines and they worked hard enough just to get everything on one DBMS though.

2 hours later…

2:52 PM

@Nick > It is worth to pay a lot of money for these licenses (i talk about Oracle, not SQL Server) because the support what you get beat the pants off other *nix dbm systems.

(from the comments)

I'm inclined to agree with the comment, at least to a certain extent. It really depends on how critical your workload it though, don't you agree?

my favourite quote from the article: "Not unless you're running a 1% sort of scenario, leveraging proprietary Oracle/SQL Server features"

have you ever worked at a shop that doesn't?

code monkey :)

3:09 PM

@JackDouglas folk who frequent this site are the1%

The rest are PHP monkeys. Given them a database is giving a typewriter to a monkey

2

You may get Shaking Stevens, but maybe mot

Mark Storey-Smith

@gbn we need a wiki for your quotes

We need to rename all databases to say "for PHP/code monkeys" or "for DB monkeys". Some could be marketed both ways. "Code Monkey MySQL" vs "DB Monkey MySQL" - same product different support team accreditation etc etc. Then just ban the 99% from dba.se ;)

@MarkStoreySmith This is pretty close :)

Mark Storey-Smith

haha nice

That's a lot of monkey

3:40 PM

@JackDouglas @BenBrocka - I'm inclined to disagree with that blog post because its scope is so narrow and naive. So MySQL can do anything SQL Server does. Wow! Really? Well, you know what? So can text files! I can create separate text files per table, even roll my own partitioning and have multiple text files per table, and develop a custom algorithm to read and lock files as needed and voila!

See? Text files can do it too!

"But you probably had to do a lot more work with the text files to get it to work."

And that's the major sell of SQL Server for me.

Not what it can do, in theory. I don't give a shit about that as much as I do about these things: Tools, ease of development, easily accessible and accurate documentation, great support community, did I mention tools already?, ease of monitoring, etc etc etc.

It's how easy it is to do things that's worth the cost, not just a technical feature.

You could replace Service Broker with Rabbit MQ, partitioning with a roll-your-own system, and check constraints with the equivalent application logic. And if it's cheaper in TIME, FRUSTRATION, MAINTAINABILITY, etc then yeah you're doing the right thing. If the only cost you see is the one you get from the vendor then you're a fucking tool.

Wow. I think this is my first ever internet rant.

4:03 PM

@Nick first ever? but you did it so well :P

horses for courses as we say over the pond. or in this case monkeys.

if all they want is a bit-bucket there is no point paying for it

everything else they are building around it is probably junk too

4:24 PM

@JackDouglas Certainly. And to the blogger's point, I wouldn't be surprised if many companies (especially the large ones) were splurging money on big licenses when they didn't need them, even taking into account the soft costs I listed.

btw @JackDouglas, we don't have a reporting tag

should we?

for this question specifically

Mark Storey-Smith

4:43 PM

@Nick first class rant

4:59 PM

lol, thank you

5:42 PM

@Nick dunno. We've got business-intelligence. Meta question to see what people think?

3 hours later…

8:27 PM

I feel alienated by @nick's rant. But I also agree with it GJ, nick.

@DTest Don't be. It's more against the blogger's incendiary style (which benefits him as a blogger) than it is against open-source RDBMSs. :)

@Nick and this site proves that you can't do everything SQL Server can with MySQL.

As I told Jack, I agree with the crux of the blogger's claim, but certainly not with the extent of it, nor with his reasoning.

@DTest Perhaps. It's probably more likely, though, that SO's engineers were mainly raised on Microsoft products.

Always go with what you're comfortable with, the standard recommendation goes.

I think I worded it wrong...DBA.SE specifically, from the questions, has shown me MySQL limitations compared to the enterprise DBMS offerings

ah, yes I would agree with that statement

@DTest A simple example of those limitations. This comes up frequently for me as a database developer.

8:43 PM

Yes. Here's hoping one day MySQL won't just ignore CHECK CONSTRAINT.

Cheers to that.

I guess I don't recognize most of these, because my experience has been to do all that in the application code. I am the 99%. I've been reforming but convincing my co-workers is arduous at best

@DTest That brings up a good point I've been meaning to ask about. At what point is it NOT obvious that a constraint should go in the database? When I asked about writing a bank schema and enforcing non-negative balances, some thought it was a business rule that belonged in the app code, some (myself included) in the database.

oh, the good ol' app vs db debate :)

Yeah... :)

8:54 PM

15

Q: What are the arguments against or for putting application logic in the database layer?

NOTE The audience of programmers.se and dba.se is different, and will have different viewpoints, so in this instance I think it's valid to duplicate What are the arguments against or for putting application logic in the database layer? on programmers.se. I couldn't find discussion on dba on this...

database-design

the question links to a similar question on programmers.se

good discussions, those

each with an obvious bent

the flaws with those discussions is that it's not clear what "app code" is

yeah it's interesting reading based on which site it's on

what's the difference between app code, business code, code to maintain consistencty, etc...?

Oh, @jcolebrand traitor "
Can we add also the ability to frigging source-control the objects as they're modified? Maybe it's just my personal gripe ... (yes, I'm obviously omitting the ways that it can be done...) – jcolebrand "

lol yeah

9:01 PM

@nick sometimes I think it depends on the shop. If your company runs code monkeys (as mine does) even the job of ensuring data integrity (eg, check constraints) that normally should be done in the data layer is just simpler to do in the application.

but as we're finding out, 'simpler' doesn't mean 'right' :)

heh, or even simpler in the long run!

but you can be the shining light

once they see that the DB can do the bitch work for them

they'll never want to do it themselves again

Right, but again MySQL's limitations come into play. Triggers, Foreign Keys, Stored Procedure error handling, etc.

yep, in some cases you are stuck doing things that should've been done for you

9:23 PM

@DTest @Nick if it weren't for my DBAs using SSMS religiously...

@jcolebrand Do your DBAs also do the development?

also, I've been AFChat cos I'm only somehow (due to sickness and lackadaisical attitudes) about 2 weeks behind

@Nick they mostly do integration and deployment stuff

then it's not as relevant to them, no?

i'm talking VS 2010 for those writing a new schema, procs, etc. and updating it regularly, especially as part of an agile dev group

yeah, but I'm talking about being able to use VS for everything, because it does rock, and it does everything that I need it to

and I can do source control with it

but I think we all have to use it or it becomes moot, no?

well, SSMS for management, monitoring, ad-hoc querying etc

VS for developing and updating a database's structure

and for deploying builds of the database - VS makes your db dev much more like code dev

and yeah, if you are using solutions then everyone will do better using VS, though in theory they could edit the SQL files generated by VS (1 per dB object)

9:30 PM

sure, of course

and I like 1 per db object

it would also make checkins much smoother

ok, back to coding so I can try and have a semblance of a weekend

word

GL @jcolebrand

take care

9:53 PM

@JackDouglas @jcolebrand - Let me know if this question better belongs on programmers.se or is too "discussion-y" for dba.se.

10:28 PM

pffft, let the community decide

0

Q: Is this a "good DBA.se" question to you?

Why should I use Visual Studio 2010 over SSMS for my database development? Nick and I got into a discussion via various places on the Stacks and he felt encouraged to ask it as a question on dba (and then he asked on chat.dba.se if this was appropriate). Since I'm too close to the question, I ca...

word

aight - i'm out. see y'all later

« first day (304 days earlier) ← previous day next day → last day (4569 days later) »

Transcript for

Nov '114

The Heap™ – Consultancy ©®

General on- and off-site discussion for dba.stackexchange.com....

frogs mysql nosql oracle postgresql sqlite sql-server

join this room
about this room

00:00

06:00

12:00

18:00

all times are UTC

site design / logo © 2024 Stack Exchange Inc; legal

mobile