Структура таблиц БД КР

Форум Сообщества Практиков Конкурентной разведки (СПКР)

Конкурентная разведка, Бизнес-разведка, Корпоративная разведка,
Деловая разведка по открытым источникам в бизнесе.
Работаем строго в рамках закона.

Дезинформация и активные мероприятия в бизнесе
Форум Сообщества Практиков Конкурентной разведки (СПКР) »   Использование баз данных в КР »   Структура таблиц БД КР
RSS

Структура таблиц БД КР

<<Назад  Вперед>>Страницы: 1 2 3 4 5 ... 7 8 9 10 11 12 13
Печать
 
Leo
Начинающий

Всего сообщений: 5
Рейтинг пользователя: 0


Ссылка


Дата регистрации на форуме:
20 сен. 2010
Для: Vinni
...
зачем, тема Вами предложенная, не интересна...
Vinni
Администратор

Всего сообщений: 2710
Рейтинг пользователя: 22


Ссылка


Дата регистрации на форуме:
5 июня 2009
Наличие одной громадной таблицы, где хранится информация о связях приводит к необходимости хранить собственно тип связи (тратится место) и замедляет поиск по такой единой таблице (придется строить много индексов для компенсации этого).

Также обратите внимание, что Игорь Нежданов написал о проблемах при эксплуатации.
[q]

В этом то и есть основная загвоздка. При проектировании БД гораздо проще (удобнее, экономнее, даже правильнее с точки зрения проектировщика) сделать одну (общую) таблицу для всех видов связей. Дабы исключить дублирование таблиц. Вариант с "индивидуальными" таблицами-посредниками на каждую пару таблиц куда более громоздкий и более трудоемкий на стадии проектирования и создания БД.

Но ситуация сильно меняется на стадии эксплуатации созданной БД рядовым юзером, который о проектировании и не слышал. Но это пока больше теоритическое умозаключение + небольшой опыт работы с искусственно созданной по принципу единой таблици связей БД (ту что сам по быстрому нарисовал и обкотал на трех юзерах). По тому и так добиваюсь подробностей.
[/q]


Любая структура хранения данных определяется прежде всего поисковыми запросами (удобством их реализации). Если пользователи делают запросы, в которых тип связи фиксирован, то хранение связей в одной таблице не поможет эффективной реализации.
Если же среди запросов преобладают те, в которых ищется информация о сущностях, типы связи между которыми могут быть различными, то одна таблица позволит повысить эффективность поиска (понадобится один SQL-запрос)


Поэтому я снова возвращаюсь к вопросу о поисковых запросах. Давайте разберемся с ними.




Leo
Начинающий

Всего сообщений: 5
Рейтинг пользователя: 0


Ссылка


Дата регистрации на форуме:
20 сен. 2010
Уважаемый Для: Vinni!
[q]
Наличие одной громадной таблицы, где хранится информация о связях приводит к необходимости хранить собственно тип связи (тратится место) и замедляет поиск по такой единой таблице (придется строить много индексов для компенсации этого).
[/q]

Информацию о связях и типах связей хранить придется в любом случае, т.к. их вариантность велика. А будет информация храница в одной таблице или в 15 одинаковых, разницы нет.
[q]
Если пользователи делают запросы, в которых тип связи фиксирован, то хранение связей в одной таблице не поможет эффективной реализации.
[/q]

Ваши высказывания говорят о не понимании Вами предмета обсуждения - СУБД CronosPro, т.к. среда Кроноса это не стандартная СУБД. И 15 однотипными базами Вы не сможете помочь пользователю выбрать правильный путь Поиск же, конечно, ведется, в основном по сущностям (основным объектам).
Я не настаиваю вообще ни на чем. Я просто демонстрирую иной подход и высказываю лично свои мысли. Вполне возможно, они не совсем верны..
Vinni
Администратор

Всего сообщений: 2710
Рейтинг пользователя: 22


Ссылка


Дата регистрации на форуме:
5 июня 2009

Leo написал:
[q]
среда Кроноса это не стандартная СУБД.
[/q]


Правильно. Вы меня опередили :wink:
Даже терминология - другая :crazy: :binocular:

Я-то говорил о структуре, исходя из того, что ИС будет реализована на базе СУБД, использующей реляционную модель данных (с третьей нормальной формой и т.д.). Разве в начале темы Игорь говорил, что структура разрабатывается сугубо конкретно под Кронос?
Тут люди и на MS Access пытаются подобные ИС создавать и Paradox из SiteSputnik пытаются приспособить.

Вы бы лучше объяснили специфику Кроноса и почему то, что плохо для реляционной СУБД нормально работает в нем.



Игорь Нежданов
Модератор форума
Прагматик
Откуда: Советский Союз
Всего сообщений: 1055
Рейтинг пользователя: 13


Ссылка


Дата регистрации на форуме:
7 июня 2009

Leo написал:
[q]
Ваши высказывания говорят о не понимании Вами предмета обсуждения - СУБД CronosPro, т.к. среда Кроноса это не стандартная СУБД.
[/q]

Так я ж вас и заманивал сюда с тайной целью чтоб вы поведали про эти особенности. По скольку большинство из нас знакомы с Кроносом на уровне пользователей. И несколько человек пробовали создавать базы под свои задачи, но на самом поверхностном уровне. Я так и не смог понять как работает статистика в кроносе и как функционируют формы ввода. :sad:


Leo написал:
[q]
Я просто демонстрирую иной подход и высказываю лично свои мысли. Вполне возможно, они не совсем верны..
[/q]

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


tungus1973 написал:
[q]
Уважаемые коллеги, а можно попросить Вас по окончании обсуждения выложить здесь пустой архив этой БД?
[/q]

Да не вопрос :beer2:


Vinni написал:
[q]
А еще лучше сделать веб-приложение, использующее что-то бесплатное и простое типа mySQL
[/q]

Та-а-ак... началось.... Vinni, пожалуйста, не забывай, что наш уровень в данной области несколько ниже твоего :blush:


Vinni написал:
[q]
Поэтому я снова возвращаюсь к вопросу о поисковых запросах. Давайте разберемся с ними.
[/q]

Это в новую тему лучше.

---
Есть вопрос - спрашивайте. На прямой вопрос будет прямой ответ...
Лаборатория Перспективных Разработок
Игорь Нежданов
Модератор форума
Прагматик
Откуда: Советский Союз
Всего сообщений: 1055
Рейтинг пользователя: 13


Ссылка


Дата регистрации на форуме:
7 июня 2009
Почитал данную тему мой знакомый и выдал вот что:

"вообщем я сторонник того, что надо сделать проще, более понятно для
пользователя.
при этом часть полей сделать словарными, чтоб отсебятину не несли, а
выбирали из предложенного.
первый файл структура, по такой схеме добавлять таблицы криминал, юрлица
и т.д. в таблицах создавать поля ТИП, для указания что это и нах ваще ;) "

Прикрепленный файл (001.jpg, 90414 байт, скачан: 434 раза)
---
Есть вопрос - спрашивайте. На прямой вопрос будет прямой ответ...
Лаборатория Перспективных Разработок
Игорь Нежданов
Модератор форума
Прагматик
Откуда: Советский Союз
Всего сообщений: 1055
Рейтинг пользователя: 13


Ссылка


Дата регистрации на форуме:
7 июня 2009
во втором файле видно тип родства, поле пренадлежит этой записи, а не
переходу на другую.
это разъяснить пользователю и нет проблем.

Прикрепленный файл (002.jpg, 74900 байт, скачан: 379 раз)
---
Есть вопрос - спрашивайте. На прямой вопрос будет прямой ответ...
Лаборатория Перспективных Разработок
Игорь Нежданов
Модератор форума
Прагматик
Откуда: Советский Союз
Всего сообщений: 1055
Рейтинг пользователя: 13


Ссылка


Дата регистрации на форуме:
7 июня 2009
третий файл, видно что есть контакты, при переходе по связи выскакивает
табличка, выбираешь тип.
при этом остальные тож указываются, просто ты перейдень на выбранную
запись.

Прикрепленный файл (003.jpg, 81898 байт, скачан: 362 раза)
---
Есть вопрос - спрашивайте. На прямой вопрос будет прямой ответ...
Лаборатория Перспективных Разработок
Leo
Начинающий

Всего сообщений: 5
Рейтинг пользователя: 0


Ссылка


Дата регистрации на форуме:
20 сен. 2010

Игорь Нежданов написал:
[q]
во втором файле видно тип родства, поле пренадлежит этой записи, а не
переходу на другую.
это разъяснить пользователю и нет проблем.
[/q]

Связь между родственниками должна быть через промежуточную таблицу, в которой прописывается степени основных объектов, типа:
1.Тип связи - родственная, 2 Описание - Иванов Иван является отцом Иванова Васи
Ведь сейчас он сын, завтра брат, послезавтра отец, дедушка и т.д.
Leo
Начинающий

Всего сообщений: 5
Рейтинг пользователя: 0


Ссылка


Дата регистрации на форуме:
20 сен. 2010
Вообще я не совсем понимаю, о чем вести дальше разговор, т.к. мне не совсем понятно, что обсуждать. Структуру и название таблиц, состав полей, теорию отображения реального мира в инфо-системах или влияние информатизации на современность?
Предлагаю начать с составом таблиц, вернее продолжить обсуждения основных объектов учета, а потом переходить к составу полей.
Честно говоря, здесь и обсуждать особенно нечего для меня, но я готов к диалогу.
<<Назад  Вперед>>Страницы: 1 2 3 4 5 ... 7 8 9 10 11 12 13
Печать
Форум Сообщества Практиков Конкурентной разведки (СПКР) »   Использование баз данных в КР »   Структура таблиц БД КР
RSS

Последние RSS
Open Source Intelligence (OSINT) Tools and Resources Handbook
Top tips on gathering information about companies by using free online sources
Новое на блоге HRразведка
Безопасность данных в MS Access
Слово как улика
20 Recon and Intel Gathering Tools used by InfoSec Professionals
What’s Changed?
10 альтернативных поисковиков
Ситуационный центр главы Республики Коми
Развёртывание ситуационных центров на базе технологии Avalanche
Как принимать сложные решения. Советы бывшего оперативника ЦРУ.
Открытая информация о "Новичке" из сети интернет.
Ген. директор "ОЗХО" Ахмет Узюмдж о "Новичке" и хим. атаке в Сирии
Онлайн-сервисы для Twitter
Коллекция для Twitter
Приложение Opera VPN закрывается
О работе разведки
Deep web и 11 поисковиков по нему
Об изначальной "лживости" любых документов
Обновление на блоге HRазведка

Самые активные 20 тем RSS
Open Source Intelligence (OSINT) Tools and Resources Handbook
Слово как улика
Top tips on gathering information about companies by using free online sources
Новое на блоге HRразведка
WebSite Watcher
Безопасность данных в MS Access