Take the 2-minute tour ×
Webmasters Stack Exchange is a question and answer site for pro webmasters. It's 100% free, no registration required.

GoDaddy allows nothing but letters and numbers in database names. Other hosting companies have similar restrictions. Could there be any technical motivation behind this?

share|improve this question
1  
Perhaps there isn't a valid reason. I've seen hosting companies that apply those restrictions to passwords... –  Álvaro G. Vicario Sep 12 '11 at 9:10
    
Keeps the regexes simple for whatever admin scripts they have, maybe? –  Peter Taylor Sep 12 '11 at 10:24
add comment

migrated from stackoverflow.com Sep 12 '11 at 9:43

This question came from our site for professional and enthusiast programmers.

4 Answers

up vote 4 down vote accepted

There can be several explanations.

One of them is security. It's definitely safer to disallow any kind of special character that might eventually be misinterpreted during a query. Of course, the best way (from the end-user perspective) would be to allow these characters and safe escape/quote them, but this behavior increases the risk a developer might actually forget to do so compromising the system.

On the other side, you have to remember you are in a shared environment. Characters like _ or - are often used internally for specify conventions. Let me show you an example.

Let's assume that your username in GoDaddy is 345678 and you are creating a mysite database. GoDaddy might decide to compose the final database as 345678_mysite and stick with this convention internally in its routing infrastructure. Allowing you to use the internal separator in your database name might actually invalidate its internal conventions where the database is USERNAME_DATABASE.

share|improve this answer
add comment

This is usually because those (special) characters are reserved for specific internal purposes and to use them in databases would require parsing.

Like ' could be used in a query to specify a LIKE clause. If the table/database name has the same character and it is not parsed, then there would be an error in the query.

So by restricting the usage of those characters, they don't need to parse the names and escape the characters.

share|improve this answer
    
The thing is they restrict characters like _ (underscore). Can you imagine _ requiring any parsing? –  Emanuil Rusev Sep 12 '11 at 7:43
    
No i don't think _ would require parsing, but then again i don't know exactly how GoDaddy works –  Jan S Sep 12 '11 at 8:02
add comment

This isn't really a programming question, and you would be better off asking the hosting provider, but here's my take.

I really couldn't tell you, to be honest. If you think about it though, you're moreso referring to a shared hosting environment, which is not designed to cater to the tech savvy. Shared hosting and the tools provided for it are moreso catered to non-technical people who need something easy to manage at an affordable rate. When you start throwing in non-alphanumeric characters (non-A-Z0-9) those type of people tend to be overwhelmed, and it often creates more frustration for both the customer, and for customer service when trying to provide assistance. I know it sounds silly that someone would be overwhelmed by more flexibility, but its true, it happens in the real world with clients.

Often times, these restrictions are put in place for simplicity for the end user. However, for us technical people who rely on things like dedicated servers more, we don't have such restrictions in that environment because we manage it ourselves, and the hosting provider doesn't really have to provide much support, nor tools.

I suppose you could just toss an email to GoDaddy or some other hosting provider and ask, and they might be able to provide an answer, or maybe not. Generally speaking customer service for hosting providers is basic, to say the least. (Unless you have a good provider like GearHost where the developers themselves provide support), or some other non-mainstream provider. They tend to provide the level of support that is sufficient for the average person, whereas technical people are more expected to be self-sufficient with their services.

As for MySQL allowing almost any character, I think its really bad practice and a bad design decision on the MySQL team. Take this for instance:

new_schema.&^

The actual name on the file system will be encoded:

new_schema@002e@0026@005e

While its neat that you can do this, its still bad practice. If its not a character supported in a file name of the Windows File System, it shouldn't be allowed. Just, horrid design in that case. Cool, more flexibile, but horrid and unnecessary.

share|improve this answer
    
Why privilege FAT and NTFS over ext3 and HFS+? –  Peter Taylor Sep 12 '11 at 17:53
    
I'm not favouring one or the other, but websites often are hosting on a broad range of hardware configurations and operating systems over time, and it is good to follow good practice and standard that can apply to most configurations. –  David Anderson - DCOM Sep 12 '11 at 21:36
add comment

Could there be any technical motivation behind this?

Very likely - in theory, mySQL database names can contain almost any character, but as they are stored as folders on filesystem level, I can see why one would want to prevent "complicated" naming schemes, especially in a mass hosting environment with thousands of customers.

One could argue that the underscore would be a harmless and useful extension to this, though. Do GoDaddy not allow even underscores?

share|improve this answer
    
Why does then MySQL allow almost any character? –  Emanuil Rusev Sep 12 '11 at 7:36
1  
@Emanuil it could be argued that it's the right thing to do in the spirit of internationalization and Unicode - you can have localized object names that way. But I've never seen anyone use it because everyone is afraid it'll break things –  Pekka 웃 Sep 12 '11 at 7:40
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.