|
|
|
TEXT vs много полей
|
|||
|---|---|---|---|
|
#18+
Собственно, вопрос в теме. Что будет быстрее, либо как "правилльнее"(если такое понятие вообще применимо к ИТ) сделать: одно поле TEXT с упакованными 50 полями, либо 50 полей. По этим 50 полям, ессно, не нужен поиск. Это просто данные. Те, по которым нужен - имеют место. И есть ли подводные камни при использовании одного TEXT? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.04.2012, 21:21 |
|
||
|
TEXT vs много полей
|
|||
|---|---|---|---|
|
#18+
Dmitriy Nikolaevich, правильное классифицировать 1. уровень детализации счас 2. завтра 3. послезавтра .... 1 скоко платят 2 будут дальше платить за детализацию 3 сделать обманку для отсоса бабла? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.04.2012, 22:33 |
|
||
|
TEXT vs много полей
|
|||
|---|---|---|---|
|
#18+
Не в деньгах дело, плачу я себе сам :) Вопрос в правильности такого подхода вообще. И не будет ли тормозить слишком мускул если много полей. Не сталкивался я просто. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.04.2012, 23:22 |
|
||
|
TEXT vs много полей
|
|||
|---|---|---|---|
|
#18+
Dmitriy Nikolaevich И есть ли подводные камни при использовании одного TEXT? Только один - чем востребованее база, тем больше вероятность, что нарушение первой нормальной формы приведет к проблемам. Dmitriy Nikolaevich По этим 50 полям, ессно, не нужен поиск. Это просто данные.Данные живут дольше программ. Dmitriy NikolaevichЧто будет быстрее,быстрее в чем - чтение/запись/поиск/вставка/обновление? Dmitriy Nikolaevichлибо как "правилльнее"(если такое понятие вообще применимо к ИТ)Давайте переформулируем вопрос так - какие выгоды/недостатки объединения достоинства 1 более короткий и простой sql 2 все отдается на откуп приложению (СУБД не выбросит надоедливый эксепшн, к дба не надо идти просить добавить поле и т.д.) недостатки 1 индекс не построить/проверок (даже совсем тупых на тип данных) не навесить 2 если приложение облажалось, то этого никто кроме пользователя не увидит до последнего момента 3 в случае изменений правил к дба идти все равно придется, подход "в лоб" для любой серьезной базы может не сработать 4 разбивание на отдельные поля потребует гораздо больших усилий чем сливание в одно поле ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.04.2012, 23:27 |
|
||
|
TEXT vs много полей
|
|||
|---|---|---|---|
|
#18+
> Собственно, вопрос в теме. Что будет быстрее, либо как "правилльнее"(если такое > понятие вообще применимо к ИТ) сделать: одно поле TEXT с упакованными 50 полями, > либо 50 полей. По этим 50 полям, ессно, не нужен поиск. Это просто данные. Те, > по которым нужен - имеют место. И есть ли подводные камни при использовании > одного TEXT? Погляди в соседний топик "как хранить атрибуты". Posted via ActualForum NNTP Server 1.5 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.04.2012, 00:29 |
|
||
|
TEXT vs много полей
|
|||
|---|---|---|---|
|
#18+
Dmitriy Nikolaevich, ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.04.2012, 09:06 |
|
||
|
TEXT vs много полей
|
|||
|---|---|---|---|
|
#18+
Пардон, что-то не так прошло. Если одно поле вместо 50, то вместо того, чтобы понять про что все это по именам колонок, теперь нужны дополнительные усилия. В МД имеет значение не тока структурирование, но и система запросов соотвествющая ей. Она расчитана в РМД, на тот чтобы работать с полями в первую очередь. Поэтому без дополнительных обстоятельств предпочтительнее 50 полей. .Ить БД создают, чтобы легче было инфу требуемую получать: не тока скорость выполнения запросо, но быстрей и проще понять как извлечь требуемое. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.04.2012, 09:14 |
|
||
|
TEXT vs много полей
|
|||
|---|---|---|---|
|
#18+
Dmitriy NikolaevichСобственно, вопрос в теме. Что будет быстрее, либо как "правилльнее"(если такое понятие вообще применимо к ИТ) сделать: одно поле TEXT с упакованными 50 полями, либо 50 полей. По этим 50 полям, ессно, не нужен поиск. Это просто данные. Те, по которым нужен - имеют место. И есть ли подводные камни при использовании одного TEXT?Если в базе данных эти 50 полей не используются никак (поиск, преобразования, вычисления, вывод), а только хранятся и передаются клиенту, и вся дальнейшая работа идёт в нём, то можно хранить как TEXT (или одиночное поле другого подходящего типа). И конечно, если есть уверенность, что в перспективе ничего не поменяется. В противном случае лучьше отдельные поля. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.04.2012, 10:04 |
|
||
|
TEXT vs много полей
|
|||
|---|---|---|---|
|
#18+
MasterZiv> Собственно, вопрос в теме. Что будет быстрее, либо как "правилльнее"(если такое > понятие вообще применимо к ИТ) сделать: одно поле TEXT с упакованными 50 полями, > либо 50 полей. По этим 50 полям, ессно, не нужен поиск. Это просто данные. Те, > по которым нужен - имеют место. И есть ли подводные камни при использовании > одного TEXT? Погляди в соседний топик "как хранить атрибуты".Смотря для чего оно, имхо это не зависит от того будет там поиск или нет. я вообще иногда использую спец поля со списком кейвордов по которым лайки делаю но это как правило бывает для расширеного поиска, когда пользователь что-то по кейвордам ищет и это поле как правило является именно только для этого все связующие таблицы всё равно присутствуют ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.04.2012, 11:31 |
|
||
|
TEXT vs много полей
|
|||
|---|---|---|---|
|
#18+
On 04/28/2012 11:04 AM, alexeyvg wrote: > Если в базе данных эти 50 полей не используются никак (поиск, преобразования, > вычисления, вывод), а только хранятся и передаются клиенту, и вся дальнейшая > работа идёт в нём, то .... тебе не нужна СУБД. Posted via ActualForum NNTP Server 1.5 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.04.2012, 11:39 |
|
||
|
TEXT vs много полей
|
|||
|---|---|---|---|
|
#18+
Может быть, кто-нибудь назовет хоть одно внятное преимущество хранения нескольких полей, упакованных в одно поле, недостижимое при раздельном хранении? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.04.2012, 11:41 |
|
||
|
TEXT vs много полей
|
|||
|---|---|---|---|
|
#18+
Dmitriy Nikolaevichодно поле TEXT с упакованными 50 полями Caché так и работает ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.04.2012, 11:59 |
|
||
|
TEXT vs много полей
|
|||
|---|---|---|---|
|
#18+
чччДМожет быть, кто-нибудь назовет хоть одно внятное преимущество хранения нескольких полей, упакованных в одно поле, недостижимое при раздельном хранении? - быстрее - меньше места - нельзя изменить данные Так довольно часто делают - хранят какой нибуть XML или эксельную табличку в базе в одном поле, и не заморачиваются, какие там внутри этого документа поля. Даже не интересуются. Всё зависит от бизнес-требований, от того, что это за данные и зачем они лежат в бд. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.04.2012, 14:28 |
|
||
|
TEXT vs много полей
|
|||
|---|---|---|---|
|
#18+
alexeyvg... Так довольно часто делают - хранят какой нибуть XML или эксельную табличку в базе в одном поле, и не заморачиваются, какие там внутри этого документа поля. Даже не интересуются. ... Данные примеры никак не связаны с описанием задачи ТС; кроме того "для этого" есть другие типы данных, не заморачиваются, какие там внутри этого документа поля. Даже не интересуются ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.04.2012, 14:38 |
|
||
|
TEXT vs много полей
|
|||
|---|---|---|---|
|
#18+
чччДДанные примеры никак не связаны с описанием задачи ТС;Я уверенно не могу ничего утверждать, описание задачи ТС дал очень лаконично :-) Но видите, он пишет, что поля в поиске не будут использоваться, это уже о чём то говорит... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.04.2012, 14:50 |
|
||
|
|
start [/forum/topic.php?fid=32&msg=37775514&tid=1541712]: |
0ms |
get settings: |
8ms |
get forum list: |
9ms |
check forum access: |
2ms |
check topic access: |
2ms |
track hit: |
65ms |
get topic data: |
6ms |
get forum data: |
2ms |
get page messages: |
31ms |
get tp. blocked users: |
1ms |
| others: | 216ms |
| total: | 342ms |
| 0 / 0 |
