Re: Storing a great many fields in a database

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.

Re: Storing a great many fields in a database

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 wo

Re: Storing a great many fields in a database

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

Re: Storing a great many fields in a database

On Mon, Jul 16, 2012 at 12:07 PM, Dr. Hawkins 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 :)

Re: Storing a great many fields in a database

I retract "most other SQL dbs" nd replace it with "some other SQL dbs". Pete lcSQL Software On Mon, Jul 16, 2012 at 12:05 PM, Ruslan Zasukhin < ruslan_zasuk...@valentina-db.com> wrote: > 2) MOST databases, for example mySQL, Postgre and our Valentina DB have > > a) STRIN

Re: Storing a great many fields in a database

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,

Re: Storing a great many fields in a database

On Mon, Jul 16, 2012 at 9:50 AM, Peter Haworth 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 moment, but need

Re: Storing a great many fields in a database

On 7/16/12 9:08 PM, "Andre Garzia" 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. Peter this is wrong inf

Re: Storing a great many fields in a database

On Mon, Jul 16, 2012 at 11:26 AM, Bob Sneidar 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 limit set, to

Re: Storing a great many fields in a database

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 remember

Re: Storing a great many fields in a database

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 wro

Re: Storing a great many fields in a database

Wha?? I thought the whole point to using VARCHAR was that it only used as much space as the actual text needed. What is the difference between TEXT and VARCHAR then? Bob On Jul 16, 2012, at 9:50 AM, Peter Haworth wrote: > SQLite does have some advantages over other dbs in this area. Since i

Re: Storing a great many fields in a database

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 length

Re: Storing a great many fields in a database

On Sun, Jul 15, 2012 at 8:13 AM, Dr. Hawkins wrote: > More seriously, to the extent that they "group" with any rhyme or reason, > it's currency values with the occasional Boolean, integer, and string. > > THe more I think about it, the more I think it will be an issue of storing > strings in their

Re: Storing a great many fields in a database

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 c

Re: Storing a great many fields in a database

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 curr

Re: Storing a great many fields in a database

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*

Re: Storing a great many fields in a database

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 ove

Re: Storing a great many fields in a database

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. O