@ErikE You get that a lot in contracting. Companies who can understand and manage development don't need contractors so much, so you tend to end up working for organisations with mildly to severely dysfunctional I.T. cultures. At least with contracting you get paid to put up with it.
@gbn - sort of interesting (in as much as peer-reviewed papers ever are). I do like the formal model for probability of getting a read that's less than k versions old.
If you could prove a certain probability value under a given load then you might be able to put some sort of SLA around the consistency of the data. Gods forbid, you might be able to use a NoSQL system with somebody who actually cares about their data.
However, measuring whether your system is actually hitting its latency SLA is left as an exercise for the reader.
@Phil SQL Server, particularly, I think - I've got a colleague here who's seeing a bit of a shortage of Oracle gigs. However, I did a google search for 'Sybase DBA' on jobserve the other day and there seemed to be plenty of demand, and the rates on offer seemed to be higher on average than SQL Server or Oracle.
Although the shortage is in ETL development rather than DBA jobs.
Well, please tell me, what's wrong with this code:
$password = "hello";
$password = md5($password);
for($i=1;$i<20;$i++){
$password = md5($password);
}
It's exactly the same as this one:
md5(md5(md5(md5(md5(md5(md5(mD5(md5(md5(md5(md5(md5(md5(md5(md5(mD5(md5(md5(md5(md5($password))))...
"Public service announcement: This question was migrated from a non-security site, after it had already accumulated (incorrect) answers with many votes. Unfortunately some of those answers contain technical errors. Unfortunately the IT Security community doesn't have enough users knowledgeable in security to counteract the sheer mass of votes from the Stack Overflow community. Therefore, please do not trust the votes here as an indicator of good security advice. – D.W. Aug 18 '11 at 8:07"
sounds like the same situation as when SO's mods migrated over here a question about TRUNCATE+DROP being faster than just DROP
@Nick do we have a canonical 'no, use order by or all bets are off' answer to link to for this?
btw an IOT is primarily used to achieve clustering (or to save space) rather than to speed up sorting data, though it may do that too in some cases :-)
What does he mean "We basically don't want to have to do an order by over a range scan 170 times a second, as the number executed will drop massively."
From the posting I don't think the priority is going to be a part of the ordering.
But back to the canonical question idea, it's probably worth doing one. Even more relevant to SQL Server as clustered indexes (basically the same thing as IOTs) are very widely used on that platform.
Actually, now if you look at it that way the question is ambiguous about whether he wants to include the priority in the ordering key.
There are times I think SO needs a whitepapers library - kind of like tag blurbs but bigger dissertations covering particular topics - inded-ordered tables for example.
Not quite wikipedia - not really just definitions of a specific term - but a collection of blurbs on commonly referenced subjects where you can refer the OP of RTFM-type questions to for some background.
if he is adding the column he is adding it to the ordering key (all columns are in the ordering key in an IOT) - the question really is where in the ordering he is adding it
@JackDouglas Now we need to know what the priority means. If the table has some parent that it refers to and you want priority 1-2 for that parent then the OP would have to be explicit about that.
Perhaps we're conflating 'poorly written question' issues with 'canonical answer' issues.
Yes, it is a bit of a RTFM question, but it's also a fairly incoherent RTFM question lacking in some specific detail that would be needed to give it a sensible answer.
@NickChammas Maybe, also it might be worth adding an index-ordered-table tag. According to @JackDouglas they work slightly differently from clustered indexes on SQL Server.
@JackDouglas - never used an IOT in anger on Oracle. I didn't know that all columns have to participate in the ordering. A clustered index doesn't require this on SQL Server.
@JackDouglas - I've asked the OP to post a separate question about his real issue. I'm afraid this has devolved into a classic case of the X-Y Problem.
Have you looked into database sharding techniques? This is a great video explaining sharding http://www.dbshards.com/rightscaleuser2010/
Hope this helps out!The company is dbshards.com
Mike
@JackDouglas From this conversation on metaso a certain level of implicit self-promotion (links to blog postings/whitepapers and suchlike) is acceptable, provided it links to relevant material. However, this answer is (a) obvious spam and (b) offtopic. Flagged as spam.
I have started working on an existing project and the previous developer had split up a table into 10 separate tables with identical schemas but different data.
The tables look like this:
[tableName_0]
[tableName_1]
[tableName_2]
[tableName_3]
[tableName_4]
[tableName_5]
[tableName_6]
[tableNam...
Guys - please don't flag stuff like this for migration unless you are the author. This was a living question and answer from a guy who's had, so far as I can tell, no participation on DBAs.
Well, please tell me, what's wrong with this code:
$password = "hello";
$password = md5($password);
for($i=1;$i<20;$i++){
$password = md5($password);
}
It's exactly the same as this one:
md5(md5(md5(md5(md5(md5(md5(mD5(md5(md5(md5(md5(md5(md5(md5(md5(mD5(md5(md5(md5(md5($password))))...
Have you looked into database sharding techniques? This is a great video explaining sharding http://www.dbshards.com/rightscaleuser2010/
Hope this helps out!The company is dbshards.com
Mike
I have started working on an existing project and the previous developer had split up a table into 10 separate tables with identical schemas but different data.
The tables look like this:
[tableName_0]
[tableName_1]
[tableName_2]
[tableName_3]
[tableName_4]
[tableName_5]
[tableName_6]
[tableNam...
