Правильная организация связей между тремя таблицами

@Barma · Регистрация: 02.01.2016

Author24 — интернет-сервис помощи студентам

Есть три таблицы, надо наладить связь так, чтобы потом можно было делать выборку по области назначения по всему каталогу! Но не получается сделать связи, в чем косяк(

@texnik-san · 03.01.2016, 01:34

1) Пока ваша база еще на этапе проектирования - сразу исправьте ляп, который в будущем может вам сильно попрортить жизнь. Слова Group, Connect и Catalog уже используются внутри самого Аксеса (Group зарезервированное слово языка построения запросов, Connect и Catalog - имена объектов системы доступа к данным), и использование этих слов в качестве имен таблиц чревато проблемами на следующих этапах создания базы.

2) В таблице Catalog переименуйте поле Область в КодОбласти, сделайте его числовым (размер поля - длинное целое), сохраните и закройте таблицу. Снова попробуйте создать связь в схеме данных (тащите поле Код таблицы Connect на поле КодОбласти).

@VinniPuh · 03.01.2016, 11:46

Эх. хоть и возникло непреодолимое желание попенять советчикам, что не упомянули про - ОБЯЗАТЕЛЬНОЕ - Счетчик (в будущих запросах и формат.) типа не предусмотрев заранее можно помучиться в будущем, хотя о чём я, у как они любят выражовываться. - не желаем слушать иностраннных враждебных советчиков.
Бог им Судбя.

@texnik-san · 03.01.2016, 12:42

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

Добавлено через 6 минут

Сообщение от texnik-san

числовой

уточнение: целочисленный. Числовые с плавающей точкой ключом быть не могут.

@VinniPuh · 03.01.2016, 13:02

Сообщение от texnik-san

Счетчик - как раз НЕ обязателен.

А вдруг нечаенно возникнет скоропостижное и непреодолимое желание чего то там подсчитать именно по этому полю, типа Соent ну иди чЁ то ещё неподобии?
не уверен, что на 123 % это даже не пригодится, даже теоретически.
Дилетанты.

@texnik-san · 03.01.2016, 13:10

И какая, по вашему, функции Count разница, что именно считать - автоматически сгенерированные числа или введенные вручную?

Добавлено через 1 минуту

Дилетанты.

Спасибо за комплимент ))

@VinniPuh · 03.01.2016, 13:49

Нук если вы ДАЖЕ спрашиваете, то у меня и вопросов то ни каких УЖЕ НЕТ..
Kapytan, Просто ни кто, даже Вы не ПОЖАЛЕЕТЕ, что создали - СЧЁТЧИК.
За СЧЁТЧИК БУДУ БОРОТЬСЯ ДОР ПОЛНОГО УВОЛЬНЕНИЯ, ТУТ, Для меня ВАЩЕ - ТОЛЬКО ТАК и НИ КАК

@Barma · 03.01.2016, 17:03 **[ТС]**

Спасибо)
Вообще, планируется база с основным назначением которой - разбивка по областям (назначениям и т.п.). Чтобы блоки литературы по категориям формировались! На первом место качественный отбор, не количественный!

@texnik-san · 03.01.2016, 17:20

Таблицы Сводный и Тип Идания: точно не перепутали, какая а стороне 1, а какая - много?

@Barma · 03.01.2016, 17:39 **[ТС]**

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

@Barma · 03.01.2016, 17:57 **[ТС]**

обновленный вариант

@texnik-san · 04.01.2016, 11:41

Сообщение от Barma

надо привязать к типу издания (носитель информации ).

Значит, точно перепутал: "Тип издания" должен быть на стороне "1", а "Сводная" на стороне "много".

@Kapytan · 09.01.2016, 12:14

Сообщение от PuhKMV

За СЧЁТЧИК БУДУ БОРОТЬСЯ ДОР ПОЛНОГО УВОЛЬНЕНИЯ, ТУТ, Для меня ВАЩЕ - ТОЛЬКО ТАК и НИ КАК

Пример возможностей использования счетчика. ВАЩЕ.

mobile · 09.01.2016, 12:46

Сообщение от Kapytan

Пример возможностей использования счетчика. ВАЩЕ.

Негативные эмоции понятны. А что сказать-то хотели?

Не по теме:

Головой можно разбить кирпич. Примеры видели. Но голову и кирпич желательно использовать иначе :-)

shanemac51 · 09.01.2016, 14:14

видимо то, что щи повторяются 5 раз

@texnik-san · 09.01.2016, 14:52

Вот тему зафлудили ))) Главное, топикстартера она давно уже не интересует )))

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

Добавлено через 6 минут
На мой взгляд, основным критерием при решении вопроса "делать ли в даной таблице ключевое поле счетчиком или не делать" является "есть ли у это таблицы целочисленный естественный ключ или нет". Совершнно очевидно, что в таблице блюд естественный ключ НЕ целочислнный. Так что суррогатный клич типа счетчик вполе уместен. Но не заменяет наобходимость добалвения уникального индеса по составному естественому ключу.

mobile · 09.01.2016, 17:17

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

Не по теме:

В сети встречал проработки о вероятности возникновения ошибок при вводе длинных текстов. Сейчас уже не вспомню где, но мой личный опыт говорит, что при длине строки больше 100 символов вероятность ошибки ассимптотически приближается к 1. Т.е. ошибки неизбежны. Так зачем же создавать систему, которая будет обязательно генерировать ошибки с большой вероятностью? Когда эту вероятность можно уменьшить достаточно простыми способами, тем же самым числовым кодом (счетчиком).

@texnik-san · 09.01.2016, 17:33

Сообщение от mobile

В сети встречал проработки о вероятности возникновения ошибок при вводе длинных текстов. Сейчас уже не вспомню где, но мой личный опыт говорит, что при длине строки больше 100 символов вероятность ошибки ассимптотически приближается к 1. Т.е. ошибки неизбежны. Так зачем же создавать систему, которая будет обязательно генерировать ошибки с большой вероятностью? Когда эту вероятность можно уменьшить достаточно простыми способами, тем же самым числовым кодом (счетчиком).

Не поняла, 1) как введение счетчика уменьшает вероятность опечатки?
2) как вероятность опечатки влияет на исходый предмет спора: "должен ли быть ключ обязательно всегда именно счетчиком, или он может быть просто числом (которое вводит пользователь)"?

@Вячеслав Я · 09.01.2016, 18:14

Попробую порассуждать:

Сообщение от texnik-san

Не поняла, 1) как введение счетчика уменьшает вероятность опечатки?

У счетчика не может быть повторов чисел и по этому каждая запись уникальна, т.е. единственна в своем роде. Можно сделать две одинаковые записи, но если у них будут разные ключевые поля, которые как таковые не несут информации, то они уже и разные;

Сообщение от texnik-san

2) как вероятность опечатки влияет на исходый предмет спора: "должен ли быть ключ обязательно всегда именно счетчиком, или он может быть просто числом (которое вводит пользователь)"?

может быть просто числом, но однажды Вы устанете искать, то самое число, которое не введено для работы.

mobile · 09.01.2016, 18:38

Сообщение от texnik-san

Не поняла, 1) как введение счетчика уменьшает вероятность опечатки?

Не ищите здесь скрытый смысл. Это немного о другом и недаром в "не по теме". Это как бы аллегория на тему. Смысл в том, что длинный текст так или иначе приводит к ошибке.

shanemac51 Модератор 11960 / 4828 / 779 Регистрация: 07.08.2010 Сообщений: 14,140 Записей в блоге: 4
	09.01.2016, 14:14	15
	видимо то, что щи повторяются 5 раз 0

@Вячеслав Я 2833 / 1375 / 215 Регистрация: 13.05.2011 Сообщений: 4,217
	09.01.2016, 18:14	19
	Попробую порассуждать: Сообщение от texnik-san Не поняла, 1) как введение счетчика уменьшает вероятность опечатки? У счетчика не может быть повторов чисел и по этому каждая запись уникальна, т.е. единственна в своем роде. Можно сделать две одинаковые записи, но если у них будут разные ключевые поля, которые как таковые не несут информации, то они уже и разные; Сообщение от texnik-san 2) как вероятность опечатки влияет на исходый предмет спора: "должен ли быть ключ обязательно всегда именно счетчиком, или он может быть просто числом (которое вводит пользователь)"? может быть просто числом, но однажды Вы устанете искать, то самое число, которое не введено для работы. 0

@Barma 7 / 0 / 0 Регистрация: 02.01.2016 Сообщений: 4
		1
	Правильная организация связей между тремя таблицами 03.01.2016, 01:13. Показов 2925. Ответов 69 Метки нет (Все метки) Есть три таблицы, надо наладить связь так, чтобы потом можно было делать выборку по области назначения по всему каталогу! Но не получается сделать связи, в чем косяк( Миниатюры 0

@texnik-san шапоклякистка 8-го дня 3679 / 2239 / 391 Регистрация: 26.06.2015 Сообщений: 4,647 Записей в блоге: 1
	03.01.2016, 01:34	2
	1) Пока ваша база еще на этапе проектирования - сразу исправьте ляп, который в будущем может вам сильно попрортить жизнь. Слова Group, Connect и Catalog уже используются внутри самого Аксеса (Group зарезервированное слово языка построения запросов, Connect и Catalog - имена объектов системы доступа к данным), и использование этих слов в качестве имен таблиц чревато проблемами на следующих этапах создания базы. 2) В таблице Catalog переименуйте поле Область в КодОбласти, сделайте его числовым (размер поля - длинное целое), сохраните и закройте таблицу. Снова попробуйте создать связь в схеме данных (тащите поле Код таблицы Connect на поле КодОбласти). 1

@VinniPuh 8860 / 5908 / 585 Регистрация: 27.03.2013 Сообщений: 19,574
	03.01.2016, 11:46	3
	Эх. хоть и возникло непреодолимое желание попенять советчикам, что не упомянули про - ОБЯЗАТЕЛЬНОЕ - Счетчик (в будущих запросах и формат.) типа не предусмотрев заранее можно помучиться в будущем, хотя о чём я, у как они любят выражовываться. - не желаем слушать иностраннных враждебных советчиков. Бог им Судбя. 1

@texnik-san шапоклякистка 8-го дня 3679 / 2239 / 391 Регистрация: 26.06.2015 Сообщений: 4,647 Записей в блоге: 1
	03.01.2016, 12:42	4
	Счетчик - как раз НЕ обязателен. Если у таблицы есть числовой смысловой ключ - а есть основания думать, что у таблицы Каталог это вполне может быть именно так (на момент создания базы у книжки могут уже иметь кем-то ранее присвоенные каталожные номера) - то нет никакой необходимости перенумеровывать их заново. Добавлено через 6 минут Сообщение от texnik-san числовой уточнение: целочисленный. Числовые с плавающей точкой ключом быть не могут. 1

@VinniPuh 8860 / 5908 / 585 Регистрация: 27.03.2013 Сообщений: 19,574
	03.01.2016, 13:02	5
	Сообщение от texnik-san Счетчик - как раз НЕ обязателен. А вдруг нечаенно возникнет скоропостижное и непреодолимое желание чего то там подсчитать именно по этому полю, типа Соent ну иди чЁ то ещё неподобии? не уверен, что на 123 % это даже не пригодится, даже теоретически. Дилетанты. 0

@texnik-san шапоклякистка 8-го дня 3679 / 2239 / 391 Регистрация: 26.06.2015 Сообщений: 4,647 Записей в блоге: 1
	03.01.2016, 13:10	6
	И какая, по вашему, функции Count разница, что именно считать - автоматически сгенерированные числа или введенные вручную? Добавлено через 1 минуту Дилетанты. Спасибо за комплимент )) 0

@VinniPuh 8860 / 5908 / 585 Регистрация: 27.03.2013 Сообщений: 19,574
	03.01.2016, 13:49	7
	Нук если вы ДАЖЕ спрашиваете, то у меня и вопросов то ни каких УЖЕ НЕТ.. Kapytan, Просто ни кто, даже Вы не ПОЖАЛЕЕТЕ, что создали - СЧЁТЧИК. За СЧЁТЧИК БУДУ БОРОТЬСЯ ДОР ПОЛНОГО УВОЛЬНЕНИЯ, ТУТ, Для меня ВАЩЕ - ТОЛЬКО ТАК и НИ КАК 0

@Barma 7 / 0 / 0 Регистрация: 02.01.2016 Сообщений: 4
	03.01.2016, 17:03 [ТС]	8
	Спасибо) Вообще, планируется база с основным назначением которой - разбивка по областям (назначениям и т.п.). Чтобы блоки литературы по категориям формировались! На первом место качественный отбор, не количественный! Миниатюры 0

@texnik-san шапоклякистка 8-го дня 3679 / 2239 / 391 Регистрация: 26.06.2015 Сообщений: 4,647 Записей в блоге: 1
	03.01.2016, 17:20	9
	Таблицы Сводный и Тип Идания: точно не перепутали, какая а стороне 1, а какая - много? 1

@Barma 7 / 0 / 0 Регистрация: 02.01.2016 Сообщений: 4
	03.01.2016, 17:39 [ТС]	10
	Пойдем обратным путем, кнопка "история искусства" внутри этого массива есть еще разбивка на темы (этой таблицы пока нет ), все это конечно надо привязать к типу издания (носитель информации ). Или пойти проще область назначения - потом тип носителя и потом все остальное �� 0

	09.01.2016, 18:38

@Barma 7 / 0 / 0 Регистрация: 02.01.2016 Сообщений: 4
	03.01.2016, 17:57 [ТС]	11
	обновленный вариант Миниатюры 0

@texnik-san шапоклякистка 8-го дня 3679 / 2239 / 391 Регистрация: 26.06.2015 Сообщений: 4,647 Записей в блоге: 1
	04.01.2016, 11:41	12
	Сообщение от Barma надо привязать к типу издания (носитель информации ). Значит, точно перепутал: "Тип издания" должен быть на стороне "1", а "Сводная" на стороне "много". 0

@Kapytan 133 / 148 / 64 Регистрация: 27.06.2013 Сообщений: 536
	09.01.2016, 12:14	13
	Сообщение от PuhKMV За СЧЁТЧИК БУДУ БОРОТЬСЯ ДОР ПОЛНОГО УВОЛЬНЕНИЯ, ТУТ, Для меня ВАЩЕ - ТОЛЬКО ТАК и НИ КАК Пример возможностей использования счетчика. ВАЩЕ. Миниатюры 0

mobile 26806 / 14485 / 3192 Регистрация: 28.04.2012 Сообщений: 15,782
	09.01.2016, 12:46	14
	Сообщение от Kapytan Пример возможностей использования счетчика. ВАЩЕ. Негативные эмоции понятны. А что сказать-то хотели? Не по теме: Головой можно разбить кирпич. Примеры видели. Но голову и кирпич желательно использовать иначе :-) 0

@texnik-san шапоклякистка 8-го дня 3679 / 2239 / 391 Регистрация: 26.06.2015 Сообщений: 4,647 Записей в блоге: 1
	09.01.2016, 14:52	16
	Вот тему зафлудили ))) Главное, топикстартера она давно уже не интересует ))) Kapytan, в хорошо разработаной таблице, исключающей многократное повторение одинаковых по смыслу записей путем создания уикальных индексов (возможно, по нескольким полям) - счетчик тоже имеет право на жизнь; а причиной показанного вами ужаса - не счетчик, а кривые руки разработчика. Добавлено через 6 минут На мой взгляд, основным критерием при решении вопроса "делать ли в даной таблице ключевое поле счетчиком или не делать" является "есть ли у это таблицы целочисленный естественный ключ или нет". Совершнно очевидно, что в таблице блюд естественный ключ НЕ целочислнный. Так что суррогатный клич типа счетчик вполе уместен. Но не заменяет наобходимость добалвения уникального индеса по составному естественому ключу. 0

mobile 26806 / 14485 / 3192 Регистрация: 28.04.2012 Сообщений: 15,782
	09.01.2016, 17:17	17
	Вот видите, Kapytan, у базовиков-акцесников мгновенно ответ нашелся на все недоумения. Собственно, Вам его говорили и раньше - уникальный ключ в справочнике на текстовое поле. Не по теме: В сети встречал проработки о вероятности возникновения ошибок при вводе длинных текстов. Сейчас уже не вспомню где, но мой личный опыт говорит, что при длине строки больше 100 символов вероятность ошибки ассимптотически приближается к 1. Т.е. ошибки неизбежны. Так зачем же создавать систему, которая будет обязательно генерировать ошибки с большой вероятностью? Когда эту вероятность можно уменьшить достаточно простыми способами, тем же самым числовым кодом (счетчиком). 0

@texnik-san шапоклякистка 8-го дня 3679 / 2239 / 391 Регистрация: 26.06.2015 Сообщений: 4,647 Записей в блоге: 1
	09.01.2016, 17:33	18
	Сообщение от mobile В сети встречал проработки о вероятности возникновения ошибок при вводе длинных текстов. Сейчас уже не вспомню где, но мой личный опыт говорит, что при длине строки больше 100 символов вероятность ошибки ассимптотически приближается к 1. Т.е. ошибки неизбежны. Так зачем же создавать систему, которая будет обязательно генерировать ошибки с большой вероятностью? Когда эту вероятность можно уменьшить достаточно простыми способами, тем же самым числовым кодом (счетчиком). Не поняла, 1) как введение счетчика уменьшает вероятность опечатки? 2) как вероятность опечатки влияет на исходый предмет спора: "должен ли быть ключ обязательно всегда именно счетчиком, или он может быть просто числом (которое вводит пользователь)"? 0

mobile 26806 / 14485 / 3192 Регистрация: 28.04.2012 Сообщений: 15,782
	09.01.2016, 18:38	20
	Сообщение от texnik-san Не поняла, 1) как введение счетчика уменьшает вероятность опечатки? Не ищите здесь скрытый смысл. Это немного о другом и недаром в "не по теме". Это как бы аллегория на тему. Смысл в том, что длинный текст так или иначе приводит к ошибке. 0