|
|||||||||
|
|||||||||
|
|||||||||
| |
|||
 |
|
|
|
|
|||||||||
|
|||||||||
|
|||||||||
| |
|||
|
|
|
|
| |||||||||
 |
|
|
«
Previous Thread
|
Next Thread
»
|
Thread Tools | Search this Thread | Display Modes |
Dev Articles Community Forums Sponsor:
|
|
Stay one step ahead of the competition. Evaluate and give feedback
on some of the hottest web development tools on the market today.
Make your opinion heard! Click
Here
|
|
#1
June 1st, 2003, 08:56 PM
|
|||
|
|||
|
Few rows but many columns. Bad idea ?
Hi,
I know that MySQL can handle few millions of rows without any problem, but lets say if I have like 300~400 or even more columns and only 2~3 rows, will it effect the performance? thanks in advance
|
|
#2
June 1st, 2003, 11:42 PM
|
|||
|
|||
|
So far I remember MySQL 3.23.X may have a maximum of 256 columns (regardless of data type) while Orcale 8 can support a maximum of 1000 columns.
I am sure about Oracle 8, but not very sure about MySQL.
|
|
#3
June 2nd, 2003, 01:10 AM
|
|||
|
|||
|
Thanks for replies
afaik, in 3.2.x versions you can have over 2000 columns in ISAM types and over 3000 columns in MyISAM types... I will never reach that amount, but I just want to know that if someone has tried to use few hundred columns in tables, and the performance...
|
|
#4
June 2nd, 2003, 01:43 AM
|
|||
|
|||
|
I've had databases with over 300 columns in dbase format with thousands of records... no problem.
I'm quite sure mysql can handle at least that many.
__________________
__________________________________________________ _ Wil Moore III, MCP | Integrations Specialist | Senior Consultant Are You Listed...? | DigitallySmooth Inc.
|
|
#6
June 2nd, 2003, 03:41 AM
|
|||
|
|||
|
Table is something like
Code:
number1 | number2 | number3 | lang| ----------------------------------------------- one | two | three | en | ------------------------------------------------ bir | iki | ьз | tr | ------------------------------------------------ 一 ｜二 ｜三 ｜jp | ------------------------------------------------- 2nd row in Turkish and 3rd row in Japanese List of words in Turkish Japanese and English. Maybe will be added more in the future. The problem is I can insert different character codes in same table, but not in the same row (at least cannot insert single-byte and double-byte chars together in the same row) So I cannot do this: Code:
enWord | jpWord | trWord ---------------------------------- one | ichi |bir two | ni |uc etc...
|
|
#7
June 2nd, 2003, 04:08 AM
|
|||
|
|||
|
Why not try it like this:
====================== ID WORD LANG 1 one en 2 two en 3 ichi jp 4 ni jp 5 bir tk 6 uc tk ====================== or even better ====================== english translation lang one ichi jp two ni jp one bir tk two uc tk ====================== then you would just need one more table to do language code lookups (eg. jp = Japanese, tk = Turkish)
|
|
#8
June 2nd, 2003, 09:25 AM
|
|||
|
|||
|
That is the reason why I am asking actually. With current code, I don't need multiple tables, loops etc. I can access whole words of one language with single recordset line (select * from blabla where lang = "tr"). If big quantity of columns does not effect performance, I will continue; if not I will choose another way. Like muliple tables, queries etc.
Anyways, I thought that if MySQL can handle few thousands for columns, few hundred won't be a problem I guess.
|
|
| Viewing: Dev Articles Community Forums > Databases > General SQL Development > Few rows but many columns. Bad idea ? |
| Thread Tools | Search this Thread |
| Display Modes | Rate This Thread |
|
|
 |
|
|
Del.icio.us
Digg
Google
Spurl
Blink
Furl
Simpy
Y! MyWeb
Linear Mode
