June 20, 2012 at 9:05 am
thanks for the question and interesting discussion - cheers
June 20, 2012 at 9:10 am
Revenant (6/20/2012)
Koen Verbeeck (6/20/2012)
paul.knibbs (6/20/2012)
a kilobyte has always been 1024 bytes as far as I'm concerned.For me, a kilobyte is still 1000 bytes. kilo = 1000
Sure. If a prospective employer offers you say $80k, you do not expect $81,920...
When negotiating salary with a prospective employer, the context is dollars, not bytes.
In the context of bytes, various meanings of "kilo", "mega" and "giga" are used in various contexts.
From http://en.wikipedia.org/wiki/Kilobyte:
Although the prefix kilo- means 1000, the term kilobyte and symbol kB or KB have historically been used to refer to either 1024 (210) bytes or 1000 (103) bytes, dependent upon context, in the fields of computer science and information technology
(with references to three online dictionaries -Oxford, Merriam-Webster, and Dictionary.com, based on Random House- that all describe kilobyte as 1024 bytes).
From http://en.wikipedia.org/wiki/Megabyte:
The term (Megabyte - HK) remains ambiguous and it can follow any one of the following common definitions:
* 1000000 bytes (10002, 106) (...)
* 1048576 bytes (10242, 220) (...)
* 1024000 bytes (1000×1024) (...)
From http://en.wikipedia.org/wiki/Gigabyte:
Today the usage of the unit gigabyte continues to depend on the context. When referring to disk storage capacities it usually means 109 bytes (...) When referring to RAM sizes it most often (...) has a binary interpretation of 10243 bytes, i.e. as an alias for gibibyte. File systems and software often list file sizes or free space in some mixture of SI units and binary units; they sometimes use SI prefixes to refer to binary interpretation – that is using a label of gigabyte or GB for a number computed in terms of gibibytes (GiB), continuing the confusion.
June 20, 2012 at 9:25 am
Easy straight forward question. Amazing features that have come with SQL Server 2012.
Thanks.
June 20, 2012 at 10:07 am
First of all if the discussion indicates the value of the question, this is a true winner.
The only thing that threw me for a minute was that the version was not stated and I did a double take. Rereading it I took it at the true meaning, what is the max size no matter what version.
Excellent, makes you think just enough and informs besides!
Not all gray hairs are Dinosaurs!
June 20, 2012 at 10:44 am
Straight forward question.
I do like the option of using the tech standard for kilo when negotiating salary.:-D
Jason...AKA CirqueDeSQLeil
_______________________________________________
I have given a name to my pain...MCM SQL Server, MVP
SQL RNNR
Posting Performance Based Questions - Gail Shaw[/url]
Learn Extended Events
June 20, 2012 at 11:21 am
SQLRNNR (6/20/2012)
Straight forward question.I do like the option of using the tech standard for kilo when negotiating salary.:-D
I used 1,000 vs 1,024 when discussing my cost of living adjustment. It worked. 🙂
June 21, 2012 at 3:35 am
tommyh (6/19/2012)
If one wants be really picky "Depends on File System" is actually the right answer.You can install 2012 on FAT32 and that have a limit to 4GB/file. The 524,272TB limit is based on 32,767 * 16TB files. Since FAT32 cant hold a 16TB file the maximum limit on a FAT32 system would be 131068GB. (4GB-1B*32767)
PS Not the answer i chose... i justed picked an answer at random since my own answer would be "More then i will ever need, so who cares" 😀
/T
Totally agree with Tommy
Dave
The impossible can be done at once, miracles may take a little longer 🙂
June 21, 2012 at 6:04 am
Hugo Kornelis (6/20/2012)
Revenant (6/20/2012)
Koen Verbeeck (6/20/2012)
paul.knibbs (6/20/2012)
a kilobyte has always been 1024 bytes as far as I'm concerned.For me, a kilobyte is still 1000 bytes. kilo = 1000
Sure. If a prospective employer offers you say $80k, you do not expect $81,920...
When negotiating salary with a prospective employer, the context is dollars, not bytes.
In the context of bytes, various meanings of "kilo", "mega" and "giga" are used in various contexts.
...
[/quote]
When buying Hard Drives they still seem to use the "context of dollars"......:-D
July 18, 2012 at 10:45 am
Rich Weissler (6/20/2012)
That just reminds me of one of my favorite quotes from my childhood. "640K ought to be enough for anybody." (Even if folks deny ever saying it.)
Well, that dates you as rather young. I remember people saying it too, but a long time after my childhood. I laughed like a drain, remembering what some people had been saying 20 years earlier, and my own idiotic remarks about the likely performance of logic simulators some years earlier than that.
Looking at the Extended Support dates yesterday, I noticed that SQL 2012 had a sunset date in 2022. Who knows what folks will be stuffing in my old SQL database servers by then. 😉 (Some silly developers refuse to upgrade their applications to run with the more current RDMS. *eyes.his.multiple.SQL2000.boxes*)
I remember a product incorporating SQL 2000 DTE that was being shipped by its (evil) manufacturers with no service pack (or maybe it had SP1, I can't remember) long after that was badly out of date - and the lunatics provided no means of applying MS fixes or SPs. Come the slammer worm, I was using my windows sysadmin privileges to break into all the systems that we or our customers had that used it so that fixes could be applied. The suppliers of this piece of rubbish (they had written many bugs, and for all practical purposes support was nonexistent) had done their best to obscure things and ensure that no-one could upgrade the underlying middleware except by applying the upgrade packs which they then decide not to provide after all. Hanging onto 2000 wasn't so bad, the crime was trying to prevent application of fixes. Of course SQL Server 2000 in 2012 is a little bit too old (I decided that our systems could be upgraded from 2000 when the first SP for 2008 was released).
Tom
July 18, 2012 at 11:12 am
David P Fisher (6/21/2012)
tommyh (6/19/2012)
If one wants be really picky "Depends on File System" is actually the right answer.You can install 2012 on FAT32 and that have a limit to 4GB/file. The 524,272TB limit is based on 32,767 * 16TB files. Since FAT32 cant hold a 16TB file the maximum limit on a FAT32 system would be 131068GB. (4GB-1B*32767)
PS Not the answer i chose... i justed picked an answer at random since my own answer would be "More then i will ever need, so who cares" 😀
/T
Totally agree with Tommy
Dave
And I totally disagree with him on both points.
On the maximum, the the correct answer (using his logic) is "it depends on the file system the persistent storage available, the version of SQL Server used, and the various limits imposed by that version of SQL Server"; going for an answer like that is pointless, and the only imaginable reason for claiming that it is the correct answer is to conceal one's lack of knowledge of what limits SQL Server actually imposes.
On "more than I will ever need, so who cares" I will just say that I remember these enormous big powerful mainframes with amazingly vast main store - 112kbytes (56k 16 bit words), 64 kbytes (16k 32 bit words), 48kbytes (64k 6 bit characters), and 96kbytes (16k 36bit words) and the people who asserted that non-one would ever near more, and now I expect my next portable personal toy to have 8 G[ibi]bytes - that's a growth factor of 75000 from the largest of those "big" machines. Those massive mainframes typically had maybe 16Mbyes of disc storage - now a portable toy is likely to have maybe a terabyte - a growth factor of 65536 from those "big" machines. I might well have suggested in the mid-60s that a gigabyte was more than I would ever imaginably want or need, but I would have been hopelessly wrong - and I suspect that that's where Tommy is today.
Tom
August 8, 2012 at 12:20 pm
Thanks for the easy question!
Viewing 11 posts - 31 through 40 (of 40 total)
You must be logged in to reply to this topic. Login to reply