Menu
▾
▴
phpwebsite-developers
|
From: Steven L. <st...@tu...> - 2002-10-22 14:37:00
|
Hello All, In response to the very long thread we have had concerning the PEAR DB and auto_increment, the development team just held a meeting to discuss our options. The decision was made to stick with the PEAR standards. So here is my +1 Please vote :) -- Steven Levin Electronic Student Services Appalachian State University Phone: 828.262.2431 PhpWebsite Development Team URL: http://phpwebsite.appstate.edu Email: st...@NO... |
|
From: Don S. <do...@se...> - 2002-10-22 14:43:34
|
So we're going with the pear sequences and the additional *_seq tables? I'll go +1 on that. I'm just paranoid of dead-locks and bottlenecks by having one table store all sequences. Don. On Tue, 22 Oct 2002, Steven Levin wrote: > Hello All, > > In response to the very long thread we have had concerning the PEAR DB > and auto_increment, the development team just held a meeting to discuss > our options. The decision was made to stick with the PEAR standards. > > So here is my +1 > > Please vote :) > > |
|
From: Darrel <da...@ii...> - 2002-10-22 15:13:19
|
You may want to take a look at this paper by Scott Ambler[1]. It compares the various approaches to getting an object identifier and then suggests an alternative called the high/low approach that might work well in your situation. The big differences are that he uses a single sequence for all objects and he allocates a set of id's to a session so that a database access is not required on each object allocation, only when the set of assigned ID's is used up. Darrel [1] http://www.ambysoft.com/mappingObjects.pdf > -----Original Message----- > From: php...@li... > [mailto:php...@li...] On > Behalf Of Don Seiler > Sent: October 22, 2002 10:43 AM > To: Steven Levin > Cc: php...@li... > Subject: Re: [Phpwebsite-developers] Sequence Tables > > > So we're going with the pear sequences and the additional > *_seq tables? > > I'll go +1 on that. > > I'm just paranoid of dead-locks and bottlenecks by having one > table store > all sequences. > > Don. > > On Tue, 22 Oct 2002, Steven Levin wrote: > > > Hello All, > > > > In response to the very long thread we have had concerning > the PEAR DB > > and auto_increment, the development team just held a meeting to > > discuss our options. The decision was made to stick with the PEAR > > standards. > > > > So here is my +1 > > > > Please vote :) > > > > > > > > ------------------------------------------------------- > This sf.net emial is sponsored by: Influence the future > of Java(TM) technology. Join the Java Community > Process(SM) (JCP(SM)) program now. > http://ad.doubleclick.net/clk;4699841;7576301;v?http://www.sun .com/javavote _______________________________________________ Phpwebsite-developers mailing list Php...@li... https://lists.sourceforge.net/lists/listinfo/phpwebsite-developers |
|
From: Matthew M. <ma...@tu...> - 2002-10-23 12:57:01
|
> I'm just paranoid of dead-locks and bottlenecks by having one table > store all sequences. > > Don. Yes, we didn't think about that. Good that it was pointed out early :) It is in CVS now. Matthew McNaney Internet Systems Architect Electronic Student Services Email: ma...@tu... URL: http://phpwebsite.appstate.edu Phone: 828-262-6493 ICQ: 141057403 |
|
From: Brian W. B. <br...@tu...> - 2002-10-23 13:13:04
|
>> I'm just paranoid of dead-locks and bottlenecks by having one table
>> store all sequences.
> Yes, we didn't think about that. Good that it was pointed out early :)
I share Don's concern... I think we should be very careful in regards to
performance issues - the DB abstraction *will* slow things down a bit no
matter how well it is implemented. But a single table for all sequences
sounds like a real bottleneck, especially with locks being thrown...
My 2 cents...
Brian
--
Brian W. Brown
Director, Electronic Student Services
Student Development
Room 269, John Thomas Hall
Appalachian State University
Boone, NC 28608
vox: 828-262-7124
fax: 828-262-2585
L I N U X
.~.
/V\
// \\
/( )\
^^-^^
Love the Penguin
|
|
From: Matthew M. <ma...@tu...> - 2002-10-23 13:27:47
|
> I share Don's concern... I think we should be very careful in regards to > performance issues - the DB abstraction *will* slow things down a bit no > matter how well it is implemented. To further this point: Database abstraction will get better. PEAR is still pretty green (heh), not in skill and talent obviously, but in age and acceptance. They WILL become the predominate library for php and we should take advantage of it. As they grow, we grow. Plus their abstraction code will probably get tighter and faster. As for the question as to why should we support many databases. Our goal is to make phpWebSite THE platform to program for. Instead of focusing on the "gee whiz", we focus on flexibility, standard, and easy of use. This draws developers which allows us to grow. More database options, means better chances for module creation. Why limit ourselves to people who just know MySQL when we can pull developers from seven other databases? Matthew McNaney Internet Systems Architect Electronic Student Services Email: ma...@tu... URL: http://phpwebsite.appstate.edu Phone: 828-262-6493 |
|
From: Adam M. <ad...@tu...> - 2002-10-23 13:42:34
|
Very well put, Matt :) Adam > To further this point: > > Database abstraction will get better. PEAR is still pretty green (heh), > not in skill and talent obviously, but in age and acceptance. They WILL > become the predominate library for php and we should take advantage of > it. > > As they grow, we grow. Plus their abstraction code will probably get > tighter and faster. > > As for the question as to why should we support many databases. Our goal > is to make phpWebSite THE platform to program for. Instead of focusing > on the "gee whiz", we focus on flexibility, standard, and easy of use. > This draws developers which allows us to grow. More database options, > means better chances for module creation. Why limit ourselves to people > who just know MySQL when we can pull developers from seven other > databases? > > > Matthew McNaney > Internet Systems Architect > Electronic Student Services > Email: ma...@tu... > URL: http://phpwebsite.appstate.edu > Phone: 828-262-6493 > > > > > ------------------------------------------------------- > This sf.net email is sponsored by: Influence the future > of Java(TM) technology. Join the Java Community > Process(SM) (JCP(SM)) program now. > http://ads.sourceforge.net/cgi-bin/redirect.pl?sunm0002en > > _______________________________________________ > Phpwebsite-developers mailing list > Php...@li... > https://lists.sourceforge.net/lists/listinfo/phpwebsite-developers --------------------------------- Adam Morton Developer - Web Technology Group Appalachian State University http://phpwebsite.appstate.edu |
|
From: Darrel <da...@ii...> - 2002-10-23 14:19:01
|
I have been experimenting with creating the Fallout database in Microsoft SQL Server. Amongst a few other things that I am investigating, I noticed that MS SQL Server chokes on the width specifier used after tinyint, int and timestamp. After reading the MySQL docs it appears that this value is completely optional and has no effect on the supported range of values. Maybe for the sake of compatibility, the width specifier could be dropped? Darrel > > As for the question as to why should we support many > databases. Our goal is to make phpWebSite THE platform to > program for. Instead of focusing on the "gee whiz", we focus > on flexibility, standard, and easy of use. This draws > developers which allows us to grow. More database options, > means better chances for module creation. Why limit ourselves > to people who just know MySQL when we can pull developers > from seven other databases? > > > Matthew McNaney |
|
From: Matthew M. <ma...@tu...> - 2002-10-24 12:45:38
|
> I have been experimenting with creating the Fallout database in > Microsoft SQL Server. Amongst a few other things that I am > investigating, I noticed that MS SQL Server chokes on the width > specifier used after tinyint, int and timestamp. After reading the > MySQL docs it appears that this value is completely optional and has no > effect on the supported range of values. > > Maybe for the sake of compatibility, the width specifier could be > dropped? > > Darrel Yes, if we can get MySQL to function without width modifiers and there aren't any reprocussions, we will drop them. Matthew McNaney Internet Systems Architect Electronic Student Services Email: ma...@tu... URL: http://phpwebsite.appstate.edu Phone: 828-262-6493 ICQ: 141057403 |
|
From: Don S. <do...@se...> - 2002-10-24 12:51:41
|
FYI I've never used width modifiers in my MySQL sql statements for those three datatypes and they've worked for me. Of course I'm just a hack. Don. On Thu, 24 Oct 2002, Matthew McNaney wrote: > > I have been experimenting with creating the Fallout database in > > Microsoft SQL Server. Amongst a few other things that I am > > investigating, I noticed that MS SQL Server chokes on the width > > specifier used after tinyint, int and timestamp. After reading the > > MySQL docs it appears that this value is completely optional and has no > > effect on the supported range of values. > > > > Maybe for the sake of compatibility, the width specifier could be > > dropped? > > > > Darrel > > Yes, if we can get MySQL to function without width modifiers and there > aren't any reprocussions, we will drop them. > > Matthew McNaney > Internet Systems Architect > Electronic Student Services > Email: ma...@tu... > URL: http://phpwebsite.appstate.edu > Phone: 828-262-6493 > ICQ: 141057403 > > > > > ------------------------------------------------------- > This sf.net email is sponsored by: Influence the future > of Java(TM) technology. Join the Java Community > Process(SM) (JCP(SM)) program now. > http://ad.doubleclick.net/clk;4729346;7592162;s?http://www.sun.com/javavote > _______________________________________________ > Phpwebsite-developers mailing list > Php...@li... > https://lists.sourceforge.net/lists/listinfo/phpwebsite-developers > |
|
From: Matthew M. <ma...@tu...> - 2002-10-24 13:10:03
|
> FYI I've never used width modifiers in my MySQL sql statements for those > three datatypes and they've worked for me. I'll try some installs without them. > Of course I'm just a hack. Modesty ;) Matthew McNaney Internet Systems Architect Electronic Student Services Email: ma...@tu... URL: http://phpwebsite.appstate.edu Phone: 828-262-6493 ICQ: 141057403 |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X