Since these words don't look so unusually short (and in fact contain one of the longest words in Tanach האחשדרפנים) and the next longest pasuk has only 41 words, I would guess this pasuk has the most letters as well, which by my count is 193 (235 if you count the spaces).

This doesn't answer your question, but in MySQL a varchar doesn't take extra disk space if you make it larger than necessary.

Are you storing in UTF-8, UTF-8-MB4, or 8859-8? The different types take different amounts of space. (3, 4, or 1 respectively, assuming you are using MySQL).

So you may just want to do varchar(65535) and not worry about it.

However if you anticipate lots of sorting operations the larger varchars do take extra temporary table space, which can slow things down. But if you sort via an index this is not a problem.

Hmm, I wonder if this is the wrong stackexchange site..... :)

Also, if your data source has nekudos the size depends on if you are storing the character composed or not. If they are not composed you need to double the space to account of the nekudos. (Although composed characters are somewhat preferred, so you should convert them.)

Well technically a varchar 65535 will take up one more byte than a varchar 255 but anyway my main concern is if I ever need to sort it will create a huge temp table
–
qwertymkNov 23 '12 at 4:13

1

Yes, that is correct, but since UTF-8 Hebrew takes two bytes per char minimum (assuming no nekudos) I'm pretty sure you'd go over 128 characters, so you need the extra byte anyway. A temp table can be a concern, but are you really ever going to sort alphabetically by the first letter of a pasuk? Otherwise it's not going to be an issue. For bible-codes you need a totally different data structure, not strings.
–
ArielNov 23 '12 at 4:39