RFTНу конечно, в строчках...
Имеем сейчас 260 000 000 (округленно) записей. А если на каждое поле - строчку - то будет 260 млрд. Интересно, как по ней отчет будет вытягиваться...

я бы отблобил ето дело.
и ограничениий на количество полей нет. ( в пределах размера блоба, конечно).

ЗЫ
даже удивительный вопрос...

АлексейК RFT660 - числовые, 200 - текстовые, 20 дат, чекбоксы в одном текстовом поле по типу YYNYNNNYNYYYNN... и т.д. до 2000 символов. Остальное - связи с другими таблицами, инфа для логов и статистики, и другое.
Где используется - в мерчендайзинге. Кто знает что такое ну... например, сопутка, тот поймет. Ассортимент из нескольких сотен наименований, плюс расположение - на полках, в корзинах, на кассах и куча другой поеб...ы.
И на структуру базы не жалуется никто... За более чем 10 лет работы менялась она ... ну только добавлялось что-то... Так что претензии насчет кривизны рук - ну уж точно не принимаются, пусть и не я это все делал.

и все в одной таблице????
типа база - хранилище объектов/документов? так при такой структуре тормоза будут страшные и толку от такой таблицы если по ней нормальный, бытрый запрос не запустить?

может вместо такой таблицы все держать в текстовом файле или XML ?

ну чаво пристали к человеку?
можно и в файле и в хмели. Но поиск индексный указателя на начало серии/номенклатуры хорошо и удобно sql-запросом проводить.
А до содержания серии ему хочется по полям, чтобы не утруждать себя программированием формирования массива. (Ну и глупо).

Типическая задача же... И решение типическое - порядковые экономии и в дисковом пространстве и в скорости доступа к информации против потери универсальности построения "заранее неизвестных запросов".
Нормальная прикладная задача и нормальный подход.

А про MySQL ... ну, скажем так - не мне судить...

RFT блобист
... потери универсальности построения "заранее неизвестных запросов".

С этим проблемов не возникает - web-интерфейс позволяет творить на свой вкус и цвет и на свои требования абсолютно любые "заранее неизвестные запросы".
блобист
А про MySQL ... ну, скажем так - не мне судить...
Это для го-о-о-раздо меньшего предприятия. Так что для ник прокатит.


%ля, а с чего все начиналось, а... Я в шоке. Вы тут а акесовском ко всем так до%%ываетесь?

абизатильно.
а то жисть - малиной.

АлексейКесли я правильно понимаю причину возникновения такой таблицы...

есть такой Гаря, он бывает на сайте митина и в бид№1.
он на семинаре озвучил свои выводы по поводу концепции в которой объекты, их свойства описываются не таблицами и полями а все держится в одной табличке - вот пример трансформации:

таблица1
датадоговора номердоговора названиенакладой датанакладной01.01.01 №12345 №3 01.02.01

преобразуем в такй вид:
типдокумента названиепараметра значениепараметрадоговор дата 01.01.01договор номер №12345накладная датанакладной 01.02.01накладная номернакладной №3

разумеется строковые договор и накладная я привел для понятности - в реале это числовой сурогатный ключ ссылающийся на таблицу с описаниями

запросы строить можно, даже удобнее
плюсов от такого решения много, подробнее можно почитать в докладе, он опубликован на сайте митина

ну конечно вовсе нет.
как блобист докладываю
типичная задача - совсем другая
из вида
id объектакоордXКоордYЛиния144.2124.8...Линия224.2114.8Линия144.3124.7

или
датаобъектцена01.01.2000123455124.8...02.01.2000123455125.8...01.01.2000123456104.8...


перейти к виду
объектцена1...цена366123455124.8...155.8123455124.8...155.8123455124.8...155.8

или виду
id объектакоордX1КоордY1...коордXNКоордYNЛиния144.2124.8...44.1124.7Линия224.2114.8...24.1114.9
резко уменьшив размер БД, объем файлового IO, и улучшив время отклика
в количество раз, пропорциональное количеству сэкономленных записей.
:)