I may very well be talking out my ass here, but wouldn't 400 different keys mean that you could factor out any one of them, making it 400 times easier to crack?
Would you please enlighten me on how an XSLT job operating on a structure like above and showing all the employees who have a salary over 100k, having more than 20 directs and have travelled in the past 12 months look like? Also please include their manages names and phone numbers int he result. And what performance it would have?
It sounds like you're kidding (or being sarcastic), and I'm not going to debug it (I'd need data, anyway.), but probably something like this:
<!--
XSLT sucks with dates, no matter what your data is arranged like. Storing dates as YYYYMMDD does
at least allow for comparisons. Also, there is no facility that I know of to retrieve the current
date, so I'm going to hard-code that.
-->
<xsl:variable name="RecentTravel" select="boolean(/root/Trips/Trip[@EmployeeID = $EmployeeID and @Date>=20030628 ])"/>
And this approach seems to perform just fine in MSXSL, which I believe is DOM-based. It might give a SAX-based engine problems, because it jumps around so much.
Lest I give a false impression, I'm not suggesting that this sort of XML replace relational databases. The point is that a roughly relational layout is still a good approach, even when you need to be working in XML.
I'd never thought of that, but it is a neat trick.
I don't know of anything that supports a single counter for the entire database (directly -- you can always use a NextID table, but you then have to do iterative inserts), but using a GUID in MS-SQL does seem to be fairly common, and I think it has a function to generate them. The downside is that you then have 128 bit keys rather than 32, which will cause a performance hit.
What exactly is the problem with SQL? I've got a couple, off the top of my head:
You can use "Select Max(EntryDate) From Customer" to find when the last customer was entered easily enough, but when you want to find out who that customer was, it gets nastier
Select *
From Customer Where EntryDate = (Select Max(EntryDate) From Customer)
Also, you can store hierarchies perfectly well (what you can store really isn't dependant on SQL), but you can't retrieve a hierarchy without involving procedural code (either extensions to SQL, like MS/Sybase T-SQL or Oracle PL-SQL, or client code).
He stopped responding when I said I thought that the dumb keys were better in a relational sense than using real data to link tables, and that I thought using real data violated the first and second normal form rules. I'm not sure if he decided I might have a point, or that I was an idiot who wasn't worth reponding to; I suspect the latter.
Join support would be nice for simple jobs, but this works really well for more complicated jobs in XSLT. You can use a for-each on "/root/Table2/Table2Row", calling a template and drill down to "/root/Table1/Table1Row[@Table1RowID='$Table1ID'] within the template. This lets you use whatever hierarchy you want, rather than being stuck with the one hierarchy the original designer chose. Just like real relational databases.
*IF* the Xbox2 will be backwards compatible (and considering the architecture of a proposed PPC chip and all, that will be very surprising
Sony put most of a PS1 on the PS2. IBM makes PowerPC, and already makes CPUs for AMD. Microsoft could work with AMD and Intel to devote a little corner of that PowerPC chip to a K-6 (if they can get the clock speed high enough to match the P-III 800 on the X-Box, just by five or six years of production process improvements) or early-model Athlon with a small cache, and take the same route.
So yes, there are cases when runtime optimizations that are unavailable at compile time can speed things a lot. Does this make Java faster? yes, if you look at the right corner case. Hell NO, if you look at the wrong one
Or basically, Java is faster if you tend to do stupid things in your programs, like use recursion for a Fibonnaci sequence.
Most of the bands I listen to I got into because of their live shows (Andrew W.K., O.A.R.).
I saw Andrew W.K. at OzzFest a couple of years ago. They had been bumped from their original main stage location to the second stage, and got booed when they played there.
don't forget the reason the Ridge exists: It's the fault line between two major techtonic plates, and new crust is constantly erupting in the middle. Not exactly the most hospitible place for a civilization, I would think.
"dBase II" was the name of Wayne Ratliff's "Vulcan" after Ashton-Tate bought it (changing their own name in the process, I believe from "Discount Software"). It may have been the first microcomputer relational database, but a bunch of other comments here are saying that Ingres also originated in 1978.
If you don't restrict yourself to commercial systems, a quick Google search brings up articles on IBM's experimental "System R" as early as 1973.
8088 = 8086-SX, in the 80386-SX sense. It was really a 16 bit processor, but used an 8 bit interface to save money on all the parts.
I'm pretty sure XT's were also 8088's, but with more RAM (and probably some other improvements, but we never had an original PC for comparison). The only computer I know of that used an actual 8086 was the PS-2 Model 25, of which my high school had a bunch until 1995 or so.
Starbucks also sells chocolate covered espresso beans (I think that's just dark roast beans). They taste great, and pack a pretty good wallop. Unfortunately, they also give you gas in a couple of hours.
I don't think it constitutes ignorance when it's something you can derive in a few seconds.
Re:His comment on Slashdot:
on
More From Tanenbaum
·
· Score: 2, Interesting
*description of Minix cut*
That's the extent of Tanenbaum's achievenemts. Not that it's negligible, far from it, but somehow Tanenbaum feels entitled to think of himself as a pillar of computer science and computer history, and act accordingly.
They discovered the delivered Ada projects had a defect rate 1/10 that...
Lockheed has done some really cool things over the years, but I just don't buy this. If they could positively identify the defect rates of these programs, they could just get rid of the bugs in the first place, in the SPARK projects *and* in the C projects. It's more likely they've got some sort of automated checked that catches exactly the same sort of thing that SPARK itself does.
Really, it looks like the SPARK program basically consists of the same program written twice, with the two versions compared for mismatches. This may be a useful tool, but it will only catch low-level errors. It would be more useful to write the program twice with different designs (and different teams), run them both, and report on when they came out with different answers.
Slashdot Mirror
I may very well be talking out my ass here, but wouldn't 400 different keys mean that you could factor out any one of them, making it 400 times easier to crack?
Would you please enlighten me on how an XSLT job operating on a structure like above and showing all the employees who have a salary over 100k, having more than 20 directs and have travelled in the past 12 months look like? Also please include their manages names and phone numbers int he result. And what performance it would have?
] " > /> />
/>
/> />, Phone #<xsl:value-of select="@PhoneNumber" />, />
It sounds like you're kidding (or being sarcastic), and I'm not going to debug it (I'd need data, anyway.), but probably something like this:
<xsl:template match="/root/Employees/Employee[@Salary>100000
<xsl:variable name="EmployeeID" select="@EmployeeID"
<xsl:variable name="NumReports" select="count(/root/Employees/Employee[@ManagerID = $EmployeeID])"
<!--
XSLT sucks with dates, no matter what your data is arranged like. Storing dates as YYYYMMDD does
at least allow for comparisons. Also, there is no facility that I know of to retrieve the current
date, so I'm going to hard-code that.
-->
<xsl:variable name="RecentTravel" select="boolean(/root/Trips/Trip[@EmployeeID = $EmployeeID and @Date>=20030628 ])"
<xsl:if test="$RecentTravel and ($NumReports>20)" >
<xsl:variable name="ManagerID" select="@ManagerID"
<xsl:text>
Name: <xsl:value-of select="@Name"
Manager Name: <xsl:value-of select="/root/Employees/Employee[@EmployeeID = $ManagerID]/@Name"
</xsl:text>
</xsl:if>
</xsl:template>
And this approach seems to perform just fine in MSXSL, which I believe is DOM-based. It might give a SAX-based engine problems, because it jumps around so much.
Lest I give a false impression, I'm not suggesting that this sort of XML replace relational databases. The point is that a roughly relational layout is still a good approach, even when you need to be working in XML.
I'd never thought of that, but it is a neat trick.
I don't know of anything that supports a single counter for the entire database (directly -- you can always use a NextID table, but you then have to do iterative inserts), but using a GUID in MS-SQL does seem to be fairly common, and I think it has a function to generate them. The downside is that you then have 128 bit keys rather than 32, which will cause a performance hit.
That's not much help if you're supposed to be working with XML.
I looked up the WITH keyword in my MS SQL docs, and it appears to be part of MDX (for OLAP cubes, I think), rather than SQL.
I've got a couple, off the top of my head:
You can use "Select Max(EntryDate) From Customer" to find when the last customer was entered easily enough, but when you want to find out who that customer was, it gets nastierAlso, you can store hierarchies perfectly well (what you can store really isn't dependant on SQL), but you can't retrieve a hierarchy without involving procedural code (either extensions to SQL, like MS/Sybase T-SQL or Oracle PL-SQL, or client code).
Much of what he, Celko, and Date complained about were actually responses by vendors to adapt to the real world.
r other name is used> fields. I was arguing with him about it on a newsgroup a few weeks ago, here.
Joe Celko seems to be particularly fixated on Identity/AutoNumber/Serial/AutoIncrement/<whateve
He stopped responding when I said I thought that the dumb keys were better in a relational sense than using real data to link tables, and that I thought using real data violated the first and second normal form rules. I'm not sure if he decided I might have a point, or that I was an idiot who wasn't worth reponding to; I suspect the latter.
Of course XML is going to be hard to represent in a relational database.
Generic XML, sure, but you can always layout your XML in a relational style, like this:
<root>
<Table1>
<Table1Row Table1RowID="1"/>
<Table1Row Table1RowID="2"/>
</Table1>
<Table2>
<Table2Row Table2RowID="1" Table1RowID="1"/>
<Table2Row Table2RowID="2" Table1RowID="1"/>
</Table1>
</root>
Join support would be nice for simple jobs, but this works really well for more complicated jobs in XSLT. You can use a for-each on "/root/Table2/Table2Row", calling a template and drill down to "/root/Table1/Table1Row[@Table1RowID='$Table1ID'] within the template. This lets you use whatever hierarchy you want, rather than being stuck with the one hierarchy the original designer chose. Just like real relational databases.
Whoever they are, they apparently have no pull in such matters.
Perhaps, but 'K' is generally the abbreviation for "Kilo" (1024), whereas 'k' is the abbreviation for "Kilo" (1000).
Personally I think the library linking issue is one of Linux's biggest achilles heels, despite a few relatively intelligent attempts to fix it.
The existence of the term "DLL Hell" would suggest that it's also one of Microsoft's biggest problems.
*IF* the Xbox2 will be backwards compatible (and considering the architecture of a proposed PPC chip and all, that will be very surprising
Sony put most of a PS1 on the PS2. IBM makes PowerPC, and already makes CPUs for AMD. Microsoft could work with AMD and Intel to devote a little corner of that PowerPC chip to a K-6 (if they can get the clock speed high enough to match the P-III 800 on the X-Box, just by five or six years of production process improvements) or early-model Athlon with a small cache, and take the same route.
So yes, there are cases when runtime optimizations that are unavailable at compile time can speed things a lot. Does this make Java faster? yes, if you look at the right corner case. Hell NO, if you look at the wrong one
Or basically, Java is faster if you tend to do stupid things in your programs, like use recursion for a Fibonnaci sequence.
What's a cassette?
It's like a cigar case, but for cigarrettes.
Most of the bands I listen to I got into because of their live shows (Andrew W.K., O.A.R.).
I saw Andrew W.K. at OzzFest a couple of years ago. They had been bumped from their original main stage location to the second stage, and got booed when they played there.
I think the Michael Douglas movie was Jewel of the Nile.
While we're on the subject, how did you like those Mig-28's (F-5's) in Top Gun?
don't forget the reason the Ridge exists: It's the fault line between two major techtonic plates, and new crust is constantly erupting in the middle. Not exactly the most hospitible place for a civilization, I would think.
Right, look how no one lives in California.
"dBase II" was the name of Wayne Ratliff's "Vulcan" after Ashton-Tate bought it (changing their own name in the process, I believe from "Discount Software"). It may have been the first microcomputer relational database, but a bunch of other comments here are saying that Ingres also originated in 1978.
If you don't restrict yourself to commercial systems, a quick Google search brings up articles on IBM's experimental "System R" as early as 1973.
8088 = 8086-SX, in the 80386-SX sense. It was really a 16 bit processor, but used an 8 bit interface to save money on all the parts.
I'm pretty sure XT's were also 8088's, but with more RAM (and probably some other improvements, but we never had an original PC for comparison). The only computer I know of that used an actual 8086 was the PS-2 Model 25, of which my high school had a bunch until 1995 or so.
Would that go in the blender, or do you use hot espresso to melt the frozen coffee?
Starbucks also sells chocolate covered espresso beans (I think that's just dark roast beans). They taste great, and pack a pretty good wallop. Unfortunately, they also give you gas in a couple of hours.
Take instant, and make it go faster.
I don't think it constitutes ignorance when it's something you can derive in a few seconds.
*description of Minix cut*
That's the extent of Tanenbaum's achievenemts. Not that it's negligible, far from it, but somehow Tanenbaum feels entitled to think of himself as a pillar of computer science and computer history, and act accordingly.
Not quite. He's also written a whole pile of books. I had one of them as the textbook for my networking class, and it's the single best textbook I've ever had for a computer class.
They discovered the delivered Ada projects had a defect rate 1/10 that...
Lockheed has done some really cool things over the years, but I just don't buy this. If they could positively identify the defect rates of these programs, they could just get rid of the bugs in the first place, in the SPARK projects *and* in the C projects. It's more likely they've got some sort of automated checked that catches exactly the same sort of thing that SPARK itself does.
Really, it looks like the SPARK program basically consists of the same program written twice, with the two versions compared for mismatches. This may be a useful tool, but it will only catch low-level errors. It would be more useful to write the program twice with different designs (and different teams), run them both, and report on when they came out with different answers.
On the other hand, Yoda was still a puppet in The Phantom Menace, and he completely looked like shit. I thought the CGI Yoda was much more believable.