Rolf wrote:
>>Oracle and PostgreSQL are not case preserving. PostgreSQL will bash to
lowercase, Oracle will bash to uppercase.<<
Given all the problems with consistency of case sensitivity and
preservation in all the DBMS systems, it looks like the safest thing to do
(if ease of portability is
On 1/24/02 8:12 AM, "Geoffrey Talvola" <[EMAIL PROTECTED]> wrote:
>
> SQL may not be case-sensitive, but all SQL databases I've used (Access, MS
> SQL Server, MySQL) are in fact case-preserving. So you can name your tables
> and columns FooBar and use them in your code as FooBar, and they will
Actually I've had some case issues.
My PostGreSQL fields match python variables - just enclode the
fieldname in double quotes and it preserves the case
SELECT "callType" from "Calls" WHERE "costOfCall" > 10.00
Also my windows MySQL is not case sensative, and made all the
tables lower case, but
On Thursday January 24, 2002 12:46 am, [EMAIL PROTECTED] wrote:
> I'm trying to decide whether to use the variable naming conventions that
> Webware uses in an RDBMS. By convention, we use "variableNamesLikeThis" in
> Python because this is what Webware uses too (trying to keep jarring style
> cha
>>I also read recently that "relational" refers to the bundling of field
values into a table row, not the relationship between that's formed when
joining two tables as I've always heard. I'm not sure I necessarily
believe it though.<<
I believe "relational" refers to the application of relation
On Thu, Jan 24, 2002 at 02:47:54AM -0500, [EMAIL PROTECTED] wrote:
> C.J. Date is always careful to say that
> all current SQL RDBMS aren't in fact relational in the sense that he had
> envisioned one to be.
I also read recently that "relational" refers to the bundling of field
values into a tabl
Mike wrote:
>>I keep on trying to get away from SQL, but I always end up coming
back. The speed and concurrency issues that the database does for
you, always end up outweighing the inconvenience.<<
Amen. Throwing everything into a decent DB like PostgreSQL solves tons of
problems. If it's any
On Thu, Jan 24, 2002 at 02:24:14AM -0500, [EMAIL PROTECTED] wrote:
> Heh, heh... well, SQL isn't Pythonic, but it does do the job...
I keep on trying to get away from SQL, but I always end up coming
back. The speed and concurrency issues that the database does for
you, always end up outweighing
Mike wrote:
>>Do you actually need such long names?<<
No, not really. I was just trying to make the problem more obvious...
>>For Python variables/keys that shadow database fields, I use exactly
the same convention. For other Python variables I've adopted the
webwareStandard. One advantage o
On Thu, Jan 24, 2002 at 12:46:00AM -0500, [EMAIL PROTECTED] wrote:
> I'm trying to decide whether to use the variable naming conventions that
> Webware uses in an RDBMS. By convention, we use "variableNamesLikeThis" in
> Python because this is what Webware uses too (trying to keep jarring style
>
I'm trying to decide whether to use the variable naming conventions that
Webware uses in an RDBMS. By convention, we use "variableNamesLikeThis" in
Python because this is what Webware uses too (trying to keep jarring style
changes to a minimum).
The problem is of course, that SQL isn't case sensi
11 matches
Mail list logo
