घर
Top.Mail.Ru Yandeks.Metrika
फोरम: "मामले";
वर्तमान संग्रह: 2002.12.02;
डाउनलोड करें: [xml.tar.bz2];

नीचे

आधार निर्माण इसी तरह की शाखाएँ खोजें


s_karm   (2002-11-11 11:32) [0]

Уважаемые мастера, подскажите как лучше построить базу.
Надо ли все данные загонять в одну таблицу или необходимо разделять их на несколько и связывать их. интересуют преимущества и недостатки.
параметров порядко 100



exit   (2002-11-11 11:37) [1]

Читай теорию реляционных СУБД - нормализация БД. Там есть и о преимуществах и о недостатках.



MsGuns   (2002-11-11 13:22) [2]

100 параметров (полей) в одной таблице - это верх маразма (Если только это не показания какой-нибудь сложной диагностики)



NickBat   (2002-11-11 13:44) [3]

>100 параметров (полей) в одной таблице - это верх маразма (Если только это не показания какой-нибудь сложной диагностики)

Да?? А если это развернутая анкета? Не считал, но думаю полей 70 точно набереться.



Jeer   (2002-11-11 13:55) [4]

Вам уже дали совет - читайте теорию реляционных баз.
Впрочем, Кодд возможно не для вас создавал эту теорию.



MsGuns   (2002-11-11 16:16) [5]

प्रश्नावली के इन 70 क्षेत्रों में, एक तिहाई का न्यूनतम "हाँ" या "नहीं" है। इस मामले में, मैं प्रश्नावली के प्रत्येक SUCH अनुभाग के लिए एक अलग क्षेत्र नहीं बनाऊंगा, लेकिन Jeer ने सब कुछ कहा। हालाँकि मैंने 230 क्षेत्रों (dbf) में एक तालिका से एक DB देखा। हाथ में झंडा!



Jeer   (2002-11-11 18:01) [6]

Например, анкета из 70 вопросов-ответов Да-Нет.
1.С одной стороны, искушение ввести в одной таблице 70 bool-полей.
Достаточно просто можно будет делать выборки по заданному критерию.

SELECT * FROM TB WHERE F1=TRUE AND F45=TRUE OR F70=FALSE

Компактно для выборки, громоздко при создании и сопровождении.
Если типы полей не только bool - еще усложняется.

2.Создать 70 таблиц
ID
PAR_ID (ссылка на ответчика)
ANSWER (тип)

Сложнее запрос, но проще модификация, дополнение
Проще создание таблиц с многозначными ответами

3. Создать одну таблицу
ID
PAR_ID (ссылка на ответчика)
ANSWER char(70)

где каждый символ отвечает за свой ответ (до 256 вариантов на один ответ)
Выборка создается через LIKE.

На мой взгляд наиболее компактный вариант, хотя с оптимизацией запросов могут быть проблемы.
Все зависит от размера выборки анкетирования



MsGuns   (2002-11-11 18:59) [7]

> Jeer © (11.11.02 18: 01)

Теоретики давно за нас все придумали 8)) В случае множества НЕЗАВИСИМЫХ триггеров используется ВЕС каждого. Т.е. предположим есть 12 ответов типа 0-нет, 1-да. Создаем ОДНО поле Integer

Значение поля Смысл
146 2+16+128 - "Да" на 2, 4 и 8 вопросы

С выборками решение чуть пооригинальнее, но пусть сам думает.



Jeer   (2002-11-11 19:37) [8]

MsGuns © (11.11.02 18: 59)
Не спорю, но число "триггеров" в случае целочисленных полей ограничено integer=31, longint=63
Для char больше свободы в числе утверждений и многозначности каждого



MsGuns   (2002-11-11 20:05) [9]

> Jeer © (11.11.02 19: 37)

С Вами, конечно, приятно подискутировать, но, похоже, сам товарищ куда-то слинял. Наверное, фигачит таблу из 100 филдов 8))))



Jeer   (2002-11-11 20:18) [10]

MsGuns © (11.11.02 20: 05)
Представил и пожалел бедного:))
С сынулей-то утряслось ?



MsGuns   (2002-11-11 20:46) [11]

Все прошло, как с белых яблонь дым. Не обращайте внимания, прошу Вас. Так, было очень паршиво, выпил, ну и понесло козла старого. Постараюсь больше не допускать такого...



s_karm   (2002-11-12 11:04) [12]

Всем спасибо (большое), напишу как получится



Sergey13   (2002-11-12 11:48) [13]

2MsGuns © (11.11.02 18: 59)
И чего вы добьетесь этим? Съэкономите 100к дискового пространства? Сумашедший эффект, особенно в эпоху 20-100 гибабайтных винтов! Еще вы получите меньшее время при чтении результата, с этим трудно спорить. Но еще вы получите громадный геморой при интерпретации полученного ответа для нормальной визуализации. И этот геморой будет мучать юзера при каждом обращении к каждой записи. А программиста при написании каждого нового отчета/формы.
Так что решение красивое, но неэффективное. ИМХО

2जेर © (11.11.02 18:01)
Примерно то-же.
>1.С одной стороны, искушение ввести в одной таблице 70 bool-полей.
Я бы поддался. Обычно самое простое решение бывает самым эффективным. Из опыта.

2s_karm (12.11.02 11:04)
>Всем спасибо (большое), напишу как получится
Красиво ушел не прощаясь. Про анкету то угадали, али нет?



Jeer   (2002-11-12 11:55) [14]

सर्गेईएक्सएनयूएमएक्स © (एक्सएनयूएमएक्स एक्सएनयूएमएक्स: एक्सएनयूएमएक्स)

Всегда важны варианты и идеи.
Жизнь сложнее чем да-нет.
Если s_karm захочется поизучать эффективность того или иного решения - у него будет эта возможность.



Sergey13   (2002-11-12 12:00) [15]

2जेर © (12.11.02 11:55)
मैं मानता हूँ



MsGuns   (2002-11-12 12:17) [16]

> सर्गेईएक्सएनयूएमएक्स © (एक्सएनयूएमएक्स एक्सएनयूएमएक्स: एक्सएनयूएमएक्स)

Да я и не спорю. Просто, ИМХО, так КРАСИВЕЕ. А мне нравится иногда не просто делать, а делать красиво. К тому же при достаточных объемах данных экономия будет не 100Mb, а несколько больше. А по поводу геморроя для программиста-клиента: что мешает все эти выборки вынести в сервер ?



Sergey13   (2002-11-13 09:58) [17]

2MsGuns © (12.11.02 12: 17)
>Просто, ИМХО, так КРАСИВЕЕ.
Красота - страшная сила. 8-)
>А мне нравится иногда не просто делать, а делать красиво.
Красиво жить не запретишь. Я предпочитаю эффективность. А иногда (не всегда конечно) 100 "некрасивых" строк кода работают в 10 раз быстрее чем 10 "красивых". Хотя красивое я тоже люблю. 8-)
>К тому же при достаточных объемах данных экономия будет не 100Mb, а несколько больше.
Ну, по объемам только отъехавший автор вопроса может судить.
>А по поводу геморроя для программиста-клиента: что мешает все эти выборки вынести в сервер ?
А что, на сервере это все будет само делаться, без программиста? И что, сервер - это ломовая лошадь которую можно грузить пока не загнется? Я за бережное отношение к серверам, их любить и лелеять надо. Тем паче в вопросе стоит Paradox. 8-)

Да и вообще, мне кажется вопрос интерпретирован не совсем так (зациклились на анкете), как задумывал автор (вот блин еще и вопрос за него додумывать!). ИМХО вопрос подразумевал что у некоторой сущности могут быть разные параметры (зависящие от вида сущности) и в этом случае стоит ли их хранить вместе (и тем самым хранить для каждой записи пустые параметры) или разносить по разным таблицам. Ну например клиенты - физические/юридические лица с, ессно, разными атрибутами. Хотя 100 параметров это для этого случая явный пребор 8-).
Если вопрос стоял так, то ИМХО все зависит от планируемых объемов этих сущностей (клиентов в моем примере). Если их будут максимум сотни, то можно и вместе хранить для простоты работы, Если тысячи и более то необходимо раздельное хранение. Хотя, смотреть все надо конкретно в каждом случае.

ЗЫ: А вообще я б таких авторов вопросов ...




MsGuns   (2002-11-13 10:35) [18]

> सर्गेईएक्सएनयूएमएक्स © (एक्सएनयूएमएक्स एक्सएनयूएमएक्स: एक्सएनयूएमएक्स)
>ЗЫ: А вообще я б таких авторов вопросов ...

Во-во ! Зонтик им в ж... И там раскрыть !!!!)))))



Leran2002   (2002-11-13 12:21) [19]

В одну таблицу кидают только ЛОХИ которые не умеют писать...



पन्ने: 1 पूरी शाखा

फोरम: "मामले";
वर्तमान संग्रह: 2002.12.02;
डाउनलोड करें: [xml.tar.bz2];

ऊपर





मेमोरी: 0.62 एमबी
समय: 0.033 c
3-4206
Yazilimci
2002-11-13 15:26
2002.12.02
Vapros:


6-4530
Artemkin
2002-09-26 18:15
2002.12.02
लॉक में दूसरे कंप्यूटर से फाइल कैसे पढ़ें। नेटवर्क?


1-4399
बनिया
2002-11-22 18:39
2002.12.02
फ़ाइलें


4-4689
Semion
2002-10-18 07:03
2002.12.02
RasDial


1-4345
lipskiy
2002-11-19 00:52
2002.12.02
TChart - क्षैतिज अक्ष में दिनांक - कैसे?





अफ्रीकी अल्बानियन अरबी भाषा अर्मेनियाई आज़रबाइजानी बस्क बेलारूसी बल्गेरियाई कैटलन सरलीकृत चीनी) चीनी पारंपरिक) क्रोएशियाई चेक डेनिश डच अंग्रेज़ी एस्तोनियावासी फिलिपिनो फिनिश फ्रेंच
गैलिशियन् जॉर्जियाई जर्मन यूनानी हाईटियन यहूदी हिंदी हंगरी आइसलैंड का इन्डोनेशियाई आयरिश इतालवी जापानी कोरियाई लात्वीयावासी लिथुआनियाई मेसीडोनियन मलायी मोलतिज़ नार्वेजियन
फ़ारसी पोलिश पुर्तगाली रोमानियाई रूसी सर्बियाई स्लोवाक स्लोवेनियाई स्पेनिश स्वाहिली स्वीडिश थाई तुर्की यूक्रेनी उर्दू वियतनामी वेल्श यहूदी बंगाली बोस्नियाई
सिबुआनो एस्पेरांतो गुजराती हौसा हमोंग ईग्बो जावानीस कन्नड़ खमेर लाओ लैटिन माओरी मराठी मंगोलियन नेपाली पंजाबी सोमाली तामिल तेलुगु योरूबा
ज़ुलु
Английский Французский Немецкий Итальянский Португальский Русский Испанский