I don't know if you are referring to SQLite or other SQL implementations,
but there is no varchar in sqlite. You can define a column as varchar but
sqlite will give it a type of TEXT internally.
SQLite does have some advantages over other dbs in this area. Since it
effectively ignores any
Bob,
SQLite will always use TEXT and allocate just as much space as necessary to
store the information at hand. I think it is a better option.
So if you just store 10 chars in that column, the TEXT field will use just
that space and nothing more.
On Mon, Jul 16, 2012 at 2:58 PM, Bob Sneidar
I think then that for SQLITE TEXT is actually synonymous with VARCHAR. It was
my understanding that VARCHAR allowed for an economical use of space, but was
slower to index. The engine would use just enough space, up to the limit set,
to store the values, truncating the excess. I seem to
On Mon, Jul 16, 2012 at 11:26 AM, Bob Sneidar b...@twft.com wrote:
I think then that for SQLITE TEXT is actually synonymous with VARCHAR. It was
my understanding that VARCHAR allowed for an economical use of space, but was
slower
to index. The engine would use just enough space, up to the
On 7/16/12 9:08 PM, Andre Garzia an...@andregarzia.com wrote:
Hi guys,
Let me explain a little LOW LEVEL ideas for VarChar and TEXT ?
1) So Peter says that SQLite always ignore length spec and store only given
chars, and Peter think that MOST OTHER dbs will eat 100 chars even if
present 1.
On Mon, Jul 16, 2012 at 9:50 AM, Peter Haworth p...@lcsql.com wrote:
I don't know if you are referring to SQLite or other SQL implementations,
but there is no varchar in sqlite. You can define a column as varchar but
sqlite will give it a type of TEXT internally.
I'm using sqlite at the
The engine (if you mean the Livecode engine) has nothing to do with it, or
at least it shouldn't. How VARCHAR works varies between SQL
implementations. For sqlite, there is no difference between TEXT and
VARCHAR - they end up using only as much storage as needed. Pretty much
the same for mySQL,
On Mon, Jul 16, 2012 at 12:07 PM, Dr. Hawkins doch...@gmail.com wrote:
If you're only ever going to access this db with LC, I'd probably use
true and false as your boolean values. If you plan on using other
tools to access it, go with 0 and 1.
It's hard to put true into a numeric value
I did not mean the LC engine I meant the SQL engine (if it is acceptable to
refer to it in that way).
Bob
On Jul 16, 2012, at 12:45 PM, Peter Haworth wrote:
The engine (if you mean the Livecode engine) has nothing to do with it, or
at least it shouldn't. How VARCHAR works varies between
On Jul 16, 2012, at 3:07 PM, Dr. Hawkins wrote:
As you noted, using REAL for currency arithmetic will get
you into rounding issues but sounds like that's not a problem. One
approach I've seen for currency values is to store them as integers
including the decimal places, e.g $100.00 would be
So you are saying we should just get rid of pennies?
Actually that story is at the same time shocking, and yet makes perfect sense.
It would be a great experiment to do that today and see what happens,
especially when people charge n.99 for things.
Bob
On Jul 16, 2012, at 3:36 PM, Peter M.
On Saturday, July 14, 2012, Mark Wieder wrote:
Saturday, July 14, 2012, 3:16:25 PM, you wrote:
Or split it into two tables, and let my get/set functions figure out
which to use, one for currency values, and the other for everything
else?
OMG. You have that many fields in *one* table? I
Ack, iPad pre launched message . . .
On Sunday, July 15, 2012, Dr. Hawkins wrote:
On Saturday, July 14, 2012, Mark Wieder wrote:
Saturday, July 14, 2012, 3:16:25 PM, you wrote:
Or split it into two tables, and let my get/set functions figure out
which to use, one for currency values,
On Saturday, July 14, 2012, Peter Haworth wrote:
Are you saying that you want to store the default, override, and actual
values in the table row of the database? If so, that deosn't feel right to
me. I'd split that into a default table, an override table, and actual
value table, each
Doc-
Saturday, July 14, 2012, 3:16:25 PM, you wrote:
Or split it into two tables, and let my get/set functions figure out
which to use, one for currency values, and the other for everything
else?
OMG. You have that many fields in *one* table? I think you need a
serious database redesign. Or
It's a little hard to decipher exactly waht your're trying to achieve here
but here's a few thoughts..
Are you saying that you want to store the default, override, and actual
values in the table row of the database? If so, that deosn't feel right to
me. I'd split that into a default table, an
16 matches
Mail list logo
