>> The TtiVisitorUpdate.AfterExecSQL in my installation has no virtual in >> it. >> Does it realted to the version of tiOPF? Mine one is tiOPF 2. > I only use tiOPF v2 and my revision number sits at r1825. Maybe you > should > get a repository update?
> The revision number can be confirm by browsing the repository with a web > browser. > > http://tiopf.svn.sourceforge.net/viewvc/tiopf/tiOPF2/Trunk/ > > or browse the tiVisitorDB.pas file directly: > http://tiopf.svn.sourceforge.net/viewvc/tiopf/tiOPF2/Trunk/Core/tiVisitorDB.pas?revision=1692&view=markup I will look at my tiVisitorDB.pas if I need to update >> I am using MySQL 5. > > I know your database is MySQL, but what database components (persistence > layer in tiOPF) are you using to access the MySQL database. As far as I > can > see, only two persistence layers in tiOPF can talk to a MySQL database: > Zeos and SqlDB.... which one do you use? I have installed Zeos 5. I wonder if Zeos can exceute INSERT followed by SELECT in one go? >> and }. I think using the integer as primary key field will be faster when >> joining a 2 million records tables with other tables. I experienced slow > > Evaluate if you really need to join 2 million records.... almost always it > is possible to limit the data you are working with by defining a better > WHERE clause. We have a large table that has 2 millions records. Yes, the join among this table and other main tables and lookup tables will have some WHERE conditions. >> Excepcially I am migrating a legacy database (desktop one) to a new MySQL >> database it took a day for data migration. > > I have been using GUID's in our products for over 5 years now. I have not > noticed any speed issues - we are using Firebird database with SqlDB > persistence layer. > > BTW: My record is a data conversion script that took 4 days of non-stop > data processing to complete. We had to always schedule it to run over > weekends. It ran on a 4x CPU SMP system with 8GB RAM, 5 disk RAID system > and MS SQL-Server database. We didn't use GUIDs as primary keys but rather > the traditional multiple fields forming a primary key. We just had a crap > load of data. :-) > > I also learned very quickly not do to a 'select * from <table>' > statements, > but rather 'select * from <table> where ...' because there was just too > many records to return. I have written a data conversion project to migrate our old desktop database to MySQL, running on my desktop pc for exactly 1 day. That was very slow in that 2 million records table when it passed the first 1 million records. Might be due to the index page relocating, splitting? Because the GUID (primary key) generated value is random, not as sequential as auto-incremented? ------------------------------------------------------------------------------ ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo _______________________________________________ tiOPF-talk mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/tiopf-talk
