*Boggle* is entirely appropriate.

Post #350,880 by static 11/18/11 6:48:24 PM Reply	Boggle is entirely appropriate. You're seeing the signs of a database programmer who Will Not Add Another Table when he can Just Add Another Column. facepalm And I thought a table with over 200 columns was a little on the excessive side... Wade. Static Scribblings http://staticsan.blogspot.com/
Post #350,898 by drook 11/18/11 10:39:31 PM Reply	Better than this We've already got a column that represents a binary value. We need to start tracking a new value that is currently one of two values, but may become several. I know! Let's alter the binary column to be an int that will contain codes that map to the cross product of all ~~possible~~ expected values. Because we don't want to add a new column and "waste" all that space. -- Drew
Post #350,909 by static 11/19/11 6:26:45 AM Reply	I guess I'm lucky. My colleagues are not averse to adding another table or column. They also try to get the type as forward-compatible as is practical. Usually that means a new table plus a lookup. At least because they're not really used to MySQL we get a slightly atypical POV on the problem. Which I approve. The biggest problem is handling brain-dead decisions made by previous programmers that are a PITA to fix. (Like using a TEXT field instead VARCHAR. And the table is 19 million rows. And ALTER TABLE on that in MySQL takes hours. We can't have the site down that long...) Just don't get me started on JDBC rules. (Sometimes I hate Java nulls.) Wade. Static Scribblings http://staticsan.blogspot.com/
Post #350,918 by mmoffitt 11/19/11 9:45:21 AM Reply	I agree on the 200. Up until this one, the largest number of columns in a single table I'd ever seen was in a datawarehouse based (loosely) on Inmon's model. It had 403 columns. I don't know much of anything about columnar databases, but in anticipation of HUGE performance problems based on the design I've seen (there are 80 tables in this database with an average of 750+ columns in each table), I've been talking to Sybase about SybaseIQ. I have no experience with it, but from the tad bit I know about the architecture, it might help this otherwise horrific database design. Knowing about this data, and knowing its for a reporting system, I can't imagine the queries will be interested in more than 10-15 columns at a time out of these tables. I might be full of crap, but if columnar databases work and perform like I think they might, it could help. One thing's certain: with this design, almost nothing I can think of could possibly hurt. ;0)
Post #350,922 by crazy 11/19/11 11:19:23 AM Reply	What is your update schedule? And will you be coding in it? I have a bit of experience with a commercial one and updates were worse then death. They would lock everyone out of the system. And you couldn't run multiple customer on a single system since you could only update one database at a time. The canned query system (visual, based on venn diagrams) was hot shit. And when drilling though TBs of data, joining and eliminating, it was lightning fast. But when we went to code against the actual engine, all hell broke loose. Then the MGR decided to toss it offshore (hehe haha) and that took it to it's death, getting the mgr and his boss canned in the process. Not often I see poor tech devisions that I argue against get punished so nicely.
Post #350,994 by mmoffitt 11/21/11 1:40:13 PM Reply	Nope. Happily I will not be directly involved in any of it. It's another team's beast. If I play this right, I can stand far enough back so as to avoid getting any of it on me. :0)
Post #351,014 by crazy 11/21/11 5:21:52 PM Reply	Smart move

Welcome to IWETHEY!