Re: [sqlite] Criteria to define two fields as Primary Key or Unique

2018-06-17 Thread Richard Damon
On 6/17/18 12:55 PM, Markos wrote: > Good Morning, > > I am a beginner in database and I'm developing a Database (with > Tcl/Tk) to control the loans of books in a reading room. > > Some users will have administrator privileges (to make loans, register > other users etc). > > I am creating a table

Re: [sqlite] Criteria to define two fields as Primary Key or Unique

2018-06-17 Thread Keith Medcalf
Also note that you probably want your application to store the password as a salted-hash, and not as a plain-text password. Otherwise someone could look up the passwords with a text editor ... --- The fact that there's a Highway to Hell but only a Stairway to Heaven says a lot about

Re: [sqlite] Criteria to define two fields as Primary Key or Unique

2018-06-17 Thread Simon Slavin
On 17 Jun 2018, at 5:55pm, Markos wrote: > I want to avoid two administrators (admin_user) with the same login but for > this I am in doubt if I put the two fields as primary key or as unique: Your ideas both have different advantages, but are not the normal way to do things. Try this

[sqlite] Criteria to define two fields as Primary Key or Unique

2018-06-17 Thread Markos
Good Morning, I am a beginner in database and I'm developing a Database (with Tcl/Tk) to control the loans of books in a reading room. Some users will have administrator privileges (to make loans, register other users etc). I am creating a table to store login and password to be used in

Re: [sqlite] .timer

2018-06-17 Thread x
Keith, I posted I was wrong about the limit offset comparison between 23.1 and 24.0 but I’m unsure where I gave you the impression the remainder of your post on the subject would be news to me. I’m well aware sqlite has to read all the rows to reach that offset. My point was that if we were

Re: [sqlite] .timer

2018-06-17 Thread Keith Medcalf
No, when you use OFFSET you are reading and discarding rows. There is no difference between: select * from t; and discarding all the results except the last row, and, select * from t limit ,1; for a table containing 1 rows. In both cases you have to read the entire table

Re: [sqlite] .timer

2018-06-17 Thread x
>Richard was saying he had sped up LIMIT queries in 3.24. I checked this out >and was running LIMIT queries >in sqlite expert (3.23.1) and my app (3.24). >The former was taking 3 times as long to run the queries (not >sure how much >of that was down to improvements or sqlite expert). Anyway, I

Re: [sqlite] .timer

2018-06-17 Thread x
It’s like having a world class soccer team and having to play in a league where the players are forced to wear stiletto heels. And it gets worse. Richard was saying he had sped up LIMIT queries in 3.24. I checked this out and was running LIMIT queries in sqlite expert (3.23.1) and my app