I want to name my mysql table column names using camel case and create php classes from these mysql tables with the same camel case names. I will be generating these php classes automatically. I'm wondering if I can rely on column name case no matter what platform I run my application on. So for example, if I name one column name "FirstName", will I ever encounter a time where reading the column name from the database will product "firstname" or something like that?
Short answer is no.
The long answer is that case-sensitivity for some things in MySQL depend on the underlying operating system. (Unix being the sensitive one)
Here is the reference to the issue in the MySQL documentation.
Consequently, the case sensitivity of the underlying operating system plays a part in the case sensitivity of database and table names. This means database and table names are not case sensitive in Windows, and case sensitive in most varieties of Unix. One notable exception is Mac OS X, which is Unix-based but uses a default file system type (HFS+) that is not case sensitive.
Also from the documentation on column names specifically:
Column, index, and stored routine names are not case sensitive on any platform, nor are column aliases. Trigger names are case sensitive, which differs from standard SQL.
MySQL is case sensitive in table and column names, and case in-sensitive in keywords.
But note that Windows is only case preserving, and file names are table names. (If you work on table "SalesAccounts" when you meant "Salesaccounts" then it will read OK on Windows and fail on Linux.
You should be OK with what you want to do, but
1) Test on Linux,
2) Test the tools you are using.
Related
I'm currently moving my project to production and found an odd situation. The database was (unfortunately) created with object names in lowercase. Now, I'm acting on table all over my 100+ stored procedures/functions, not always keeping in mind the fact that I should use lowercase for table names.
I made a simple test:
select * from mytable ;
yields all the records in the table, whereas:
select * from Mytable ;
returns a "table does not exist" error.
Is there any solution someone could suggest besides going one by one through each and every stored procedure/function and correct the case of the table names?
Thanking in advance for any life-saving suggestion.
From the MySQL documentation on cases in identifiers:
In MySQL, databases correspond to directories within the data
directory. Each table within a database corresponds to at least one
file within the database directory (and possibly more, depending on
the storage engine). Triggers also correspond to files. Consequently,
the case sensitivity of the underlying operating system plays a part
in the case sensitivity of database, table, and trigger names.
I would probably take the time to make everything lower case because it will save you headaches further down the line. If you have a client with a decent editor like MySQL Workbench then you can do these replaces with a quick find and replace.
EDIT:
According to the documentation, you can try setting the lower_case_table_names system variable to 1, which will:
Table names are stored in lowercase on disk and name comparisons are
not case sensitive. MySQL converts all table names to lowercase on
storage and lookup. This behavior also applies to database names and
table aliases.
This might solve your problem if all of the table had been created with lowercase on disk.
Does anyone know HOW I might preserve case in my table names please
(Win 10 using phpMyAdmin,latest xampp distribution). Could this be because xampp is using MariaDB instead of mySQL?
Table names being rewritten to all lowercase.
Read on phpMyAdmin site that to use preserve case I should add:
'set-variable=lower_case_table_names=0'
this stopped mySQL starting with an error message:
[ERROR] c:\xampp\mysql\bin\mysqld.exe: unknown variable 'set-variable=lower_case_table_names=0'
Then after reading an answer here I learned I should use lower_case_table_names=0so aded that to my.ini and still got the same error.
I then spent 20 mins trying to work out where my set-variable=lower_case_table_names=0 was set. (Thought it must be cached or duplicated or something.)
In desperation I deleted the lower_case_table_names=0 and the error disappeared. I put it back and got the
[ERROR] c:\xampp\mysql\bin\mysqld.exe: unknown variable 'set-variable=lower_case_table_names=0' error. IE they seem to be aliases with the error reporting translating. Somewhat irritating.
You should read the documentation bit more carefully, specifically identifier case sensitivity section.
In MySQL, databases correspond to directories within the data
directory. Each table within a database corresponds to at least one
file within the database directory (and possibly more, depending on
the storage engine). Triggers also correspond to files. Consequently,
the case sensitivity of the underlying operating system plays a part
in the case sensitivity of database, table, and trigger names. This
means such names are not case sensitive in Windows, but are case
sensitive in most varieties of Unix.
Value Meaning
0 Table and database names are stored on disk using the
lettercase specified in the CREATE TABLE or CREATE DATABASE statement.
Name comparisons are case sensitive. You should not set this
variable to 0 if you are running MySQL on a system that has
case-insensitive file names (such as Windows or OS X). If you force
this variable to 0 with --lower-case-table-names=0 on a
case-insensitive file system and access MyISAM tablenames using
different lettercases, index corruption may result. 1 Table names are
stored in lowercase on disk and name comparisons are not case
sensitive. MySQL converts all table names to lowercase on storage and
lookup. This behavior also applies to database names and table
aliases. 2 Table and database names are stored on disk using the
lettercase specified in the CREATE TABLE or CREATE DATABASE statement,
but MySQL converts them to lowercase on lookup. Name comparisons are
not case sensitive. This works only on file systems that are not case
sensitive! InnoDB table names are stored in lowercase, as for
lower_case_table_names=1.
To summarise: on windows you should not set lower_case_table_names to 0. If you want to preserve the letter case for table names on windows, then set lower_case_table_names to 2.
The using system variables section explains how to set a system variable in various ways.
Putting lower_case_table_names=2 in your my.ini files allows the use of upper and lower case in tabel names... BUT .... BIG BUT... it does NOT allow you to put upper case letters into EXISTING file names.
The solution is to COPY your table to a new table with the "correct" name.
However as this only changes the appearance of the table names (tables are stored in lower case files) you must use an intermediate table.
EG you want the table name to be HelloWorld but you discover it is stored as helloworld. Add the line above to your my.ini file then make a copy helloworld to a new table, say "helloTemp", delete helloworld copy helloTemp to HelloWorld delete helloTemp and you have a table with HelloWorld as the name.
In Linux server I am Configure Apache and PhpMyadmin.
In the database my table's name is mst_vehicle
when I fire a query like select * from mst_vehicle it will give right result, but
When I fire a query like select * from Mst_Vehicle It will give an error.
Please help me how to resolve this problem.
I import the database from windows to linux phpmyadmin and my windows database is already with lower case table name.
Database and table names are not case sensitive in Windows, and case sensitive in most varieties of Unix.
In MySQL, databases correspond to directories within the data
directory. Each table within a database corresponds to at least one
file within the database directory (and possibly more, depending on
the storage engine). Consequently, the case sensitivity of the
underlying operating system plays a part in the case sensitivity of
database and table names. This means database and table names are not
case sensitive in Windows, and case sensitive in most varieties of
Unix. One notable exception is Mac OS X, which is Unix-based but uses
a default file system type (HFS+) that is not case sensitive.
Have a look at Identifier Case Sensitivity.
You can get the correct case-sensitive table name from case-ignorant name by doing this:
select table_name from information_schema.tables where lower(table_name)="mst_vehicle" and table_schema="YourDatabaseName"
It will however add a performance penalty.
Back when I started with database design, for some reason it was recommended that you always use snake case (my_table_name) for tables and columns. I think this was especially true in MySQL. The reasoning was there were instances where capitalization would be lost or enforced. Flash forward to today and I see a lot of people using Pascal Case ("MyTableName"), which I would prefer.
Is there any reason to still use snake case for table and column names? Are there any instances where capitalization could be lost or enforced (say if changing database engines, OS's, etc.)?
SQL is case-insensitive. Many databases fold names to lowercase when creating tables, so capitalisation is lost.
The only portable way to preserve "words" within names is to use snake case.
from http://dev.mysql.com/doc/refman/5.0/en/identifier-case-sensitivity.html:
"In MySQL, databases correspond to directories within the data directory. Each table within a database corresponds to at least one file within the database directory (and possibly more, depending on the storage engine). Consequently, the case sensitivity of the underlying operating system plays a part in the case sensitivity of database and table names. This means database and table names are not case sensitive in Windows, and case sensitive in most varieties of Unix. One notable exception is Mac OS X, which is Unix-based but uses a default file system type (HFS+) that is not case sensitive."
In short, it depends on the filesystem underneath the database.
Nowadays, most mysql servers run on linux systems which have an ext3/ext4/bttrfs/namesomeother filesystem which are case sensitive. FAT12, for example, was not case sensitive and not even case preserving, so the database MyDB may not be found by mysql after creation. Fat32 and HFS+ are not case sensitive, but it is case preserving; so you can get into trouble with Mydb and myDB.
So if you know your database may be hosted on a FAT12 system, you may still want to make sure you watch case.
SQL is case insensitive, unless you are using delimited identifiers. The example above compares a normal identifier with a delimited one. Identifier rules go out the window when using delimited identifiers; this is a valid identifier "4argo ###$# yourself".
Words strung together are harder to read than words separated, and they are more prone to spelling errors, especially if plurals are sometimes involved.
Delimited identifiers allow you to mimic case-sensitive application languages, but they can cause difficulties in things like metadata searches. You can easily end up with vendor-specific behavior, which is an obvious pain.
Some DBMS were implemented before SQL was standardized to fold to uppercase; they will never change. (My guess is IBM won an argument at some meeting and made it uppercase.) And, they should not have to, as long as case insensitivity is handled correctly.
It's a bad idea to model your schema based on how the particular DBMS you are using is implemented.
If I have a column names called category_id and Category_Id, are they different?
And if I have table called category and Category, are they different?
On Unix, table names are case sensitive. On Windows, they are not. Fun, isn't it? Kinda like their respective file systems. Do you think it's a coincidence?
In other words, if you are developing on Windows but planning on deploying to a Linux machine, better test your SQL against a Linux-based MySQL too, or be prepared for mysterious "table not found" errors at prod time. VMs are cheap these days.
Field (column) names are case-insensitive regardless.
EDIT: we're talking about the operating system on the MySQL server machine, not client.
From the MySQL documentation:
database and table names are not case sensitive in Windows, and case
sensitive in most varieties of Unix. One notable exception is Mac OS
X, which is Unix-based but uses a default file system type (HFS+) that
is not case sensitive.
and
Column and index names are not case sensitive on any platform, nor are column aliases.
For database and table names, it depends on the underlying operating system.
See 8.2.2. Identifier Case Sensitivity
Strangely enough it seems to be case sensitive in the MySQL Workbench even on Windows.
We just tried to alter the results of a SELECT statement but the Workbench didn't let us, complaining that our query did not include the table's primary key (which it did but in lower-case) so the result was read-only. Running the same query with the primary key in proper case (ID instead of id) would let us edit the results as expected.