Снова вопрос к мастерам. Нужна идея.

← →
Galinka (2002-07-17 10:09) [0]

Уважаемые мастаки, на этот раз необходимо реализовать следующее:
Имеется таблица Paradox, много (12) полей.Из них : класс, фамилия, имя.При ввводе след.ученика необходима проверка , не был ли он туда уже заведен ранее (могут в классе быть однофамильцы). Можно ли это сделать как-то хитро (сделать чтоб были уникальными три поля в совокупности, а не каждое отдельно), чтоб не делать простой перебор по всем существующим записям? Или лучше перебором, тк в таблице врядли будет много больше 1000 записей? Жду ваших комментариев.
Спасбо всем заранее.

← →
Evgeny7 (2002-07-17 10:21) [1]

Можно 1. использовать компанент QuantntumGid это даст возможность перед внесением нового ученика проверять внесён он или нет, 2. попробуй сделать справочники, куда будут заноситься ИФО учеников и каждому будет присвоен свой уникальный код. Далее при работе в программе пользователь уже не вводит каждого ученика, а выбирает его из списка, например с помощью того же QuantntumGid.

← →
Sergey13 (2002-07-17 10:24) [2]

Теоретически, лучше перебор, т.к. никто не застрахован от полных тезок. Тогда надо еще дату рождения в уникальный индекс? А если и она одинаковая (теоретически возможно). ИНН пока не присвоен всем людям.
По моему вообще проблемы нет. Для класса - визуально отследить 20-30 записей по ученикам - не составляет никакого труда. В крайнем случае удалить дубликаты. Не думаю что ошибка при вводе такого рода останется незамеченной 11 лет обучения.

← →
Evgeny7 (2002-07-17 10:30) [3]

Есть интересная идея, напиши свой e-mail, пришлю сегодня или завтро.

← →
Johnmen (2002-07-17 10:30) [4]

Если нужна уникальность по совокупности полей, то строй индекс по этой совокупности. При попытках добавить/изменить на уже сущесвующее будет возбуждаться ошибка, которую и обрабатывай.

← →
Galinka (2002-07-17 10:44) [5]

Evgeny7
Вот мой E-mail: g_laushkina@pisem.net
Только пиши, пожалуйста с тем расчетом, что я только начинаю изучать БД, и знаю их довольно плохо.Поэтому такие вопросы и задаю.

Johnmen ©
Пожалуйста, объясни мне как строится индекс по совокупности. Я не знаю как это можно реализовать.

2 ALL
Большое спасибо за ответы, только пишите поподробнее. Я плохо разбираюсь пока в предмете. Поэтому иногда мне требуется объяснение как для чайника. Прошу прощение за невежество.

← →
Johnmen (2002-07-17 11:24) [6]

Как с помощью сервисных программок типа Database Desktop тебе скажут те, кто ими пользуется.
А со стороны приложения могу посоветовать попробовать выполнить запрос типа CREATE INDEX ....

← →
Val (2002-07-17 11:47) [7]

>Evgeny7 (17.07.02 10:21)
подобные вопросы, по-моему, необходимо решать на стадии проектирования бд, а не разработки интерфейса.
>Sergey13 © (17.07.02 10:24)
..Для класса - визуально отследить 20-30..
у нее в таблице есть поле класс, значит таблица будет содержать данные не по одному классу. А зачем отслеживать самому, если есть средства для этого СУБД? Тут нужно смотреть на всю таблицу, может еще что можно внести индекс.
>Galinka ©
Думается, самое разумное, классическое решение предлагает Johnmen ©. Заодно и индексы подучите :)

← →
kaif (2002-07-17 11:59) [8]

Предположим, мы имеем уникальный индекс (Ф.,И.,О.,Дата рождения)
При вводе данных вполне возможна ситуация:
1. Ошибка при вводе, например, фамилии. Но запись уже добавлена.
2. Попытка (уже невозможность) исправить ошибку, так как возникает нарушение уникального ключа. Теперь такую запись нужно удалять. А что, если уже имеются введенные важные сведения в другой таблице, связанные с данной записью?
--------
Одним словом, мое мнение:
1. Первичный ключ в такой таблице должен быть простым и суррогатным (просто нумерация типа автоинкремент).
2. Проверка на дубликат должна быть интеллектуальной, допускающей сообщения в случае "сильно похожих" учеников, например, отличающихся 1 или 2 буквами в Ф.И.О. а еще лучше список всех таких при любом добавлении, чтобы убедиться, что ученик вводится впервые. Сканирование таблицы не страшно, если только речь не идет обо всех учениках России. Если предполагается иметь 2-3 тыс. учеников, то сканирование будет работать быстро.
3. Для ускорения упорядочиваний по ФИО нужно иметь неуникальный индекс по полям Фамилия+Имя+Отчество. Так как возможны полные тезки. И такое бывает, несмотря на кажущуюся маловероятность.

← →
MsGuns (2002-07-17 12:11) [9]

Согласен с Val и Johnmen, но добавлю:

Это похоже на типичный случай кадровой БД. (Каждый ФИО типа Главный ключ). В этом случае в грамотных разработках исп-ся не совокупность 3-х полей ("Имя","Отчество","Фамилия") или комп-го поля ФИО, а ТАБЕЛЬНЫЙ НОМЕР (или что-то вроде этого). Именно это поле является главным связующим компонентом в такого рода БД. Это поле обычно невелико (String(6)) или ShortInt, что приводит к существенной экономии размеров таблиц БД и, соотв-но, к повышению скорости работы всего проекта.

При добавлении же в Гл.Справочник (Картотеку), ФИО можно сверять не уходя с добавляемой записи (метод LookUp), а повтор Номера (Таб.номера) сам по себе исключен (KeyViolate)

Все же "дочерние" таблицы (вроде состава класса, табелей и пр) базируются на основе Гл.ключа при определении товарищей (т.е. вместо ФИО в таких таблах хранится Таб.Номер). Т.е. типовая 2-уровневая кадровая модель БД.

← →
Val (2002-07-17 12:15) [10]

>kaif © (17.07.02 11:59)
кто говорил о создании составного primary key? естественно создать ID как РК, а ФИО+чего-нибудь еще, как Unique Index, хотя не понятно, чего же хочет автор, если сама понимает, что тезки - нормальное явление.

← →
MsGuns (2002-07-17 12:24) [11]

> Kaif
Клю-то суррогатный, но НИ В КОЕМ СЛУЧАЕ не автоикремент !!!
Таб.N - штука весьма полезная. Я когда-то работал на радиозаводе с 15000 чел. Так бухгалтера в расчетной не помнили ФИО, зато помнили таб.номера своих "подопечных".
Пусть это поле вводит юзер !!!

← →
kaif (2002-07-17 12:31) [12]

2 Val © (17.07.02 12:15)
Не спорю.
Вообще, стоит подсказать автору вопроса, что одной таблицей он тут не отделается. Как минимум, нужно иметь 2 таблицы:
1. Классы
2. Ученики
Таблица классов должна, скорее всего иметь поле года создания класса, например, 2000. и поле буквы, например, "а". Уникальность в этой таблице - год + буква.
Возможно, уже в приложении нужно будет вычисляемое поле, чтобы из этих данных получать строку 3-й "а" (в отчетах).
В общем, нужно автору вопроса все свои 12 полей привести, чтобы получить грамотный совет...
А уникальность ФИО учеников - точно гиблое дело. Достаточно одного полного тезки, чтобы программа стала нехорошей.

← →
MsGuns (2002-07-17 12:38) [13]

>Kaif
Ну а третью-то ? Типа табелей с оценками. Насколько я понял, это одна из задач проекта ?

← →
Val (2002-07-17 12:41) [14]

опять гаданье :)

← →
Galinka (2002-07-17 13:49) [15]

Смысл проекта гараздо проще: надо отмечать кто оплатил за обучение в конкретном месяце, а кто нет. Поэтому большинство полей-логические по названием месяцев. Оценки вписывать никто не будет. Заполнять базу будет учительница, без знаний о справочниках. -> их делать не надо. Единственное что я полагаю нужно, это предусмотреть что человек с такими ФИО в один и тот же класс не был занесен дважды. Для простоты решения можно даже каждый год стирать БД, тк в этой школе каждый год экзамены переводные и ~половина отсеивается.-> Нет необходимости хранить данные больше года. БД нужна только для формирования отчетов: кто заплотил, кто нет. Чтобы они не квиточки об оплате каждый раз перебирали, а могли за минуту распечатать все что интересует.

Если не сложно, объясните как можно сделать индекс по 4-м полям(ФИО+класс).

← →
Johnmen (2002-07-17 13:56) [16]

Вот из хелпа :
CREATE [UNIQUE] [ASC[ENDING] | DESC[ENDING]] INDEX index
ON table (col [, col …]);

← →
MsGuns (2002-07-17 14:00) [17]

>Galinka
Сейчас нарисую тебе модель БД и набросок (рисунок) формы и отправлю на мыло

← →
Galinka (2002-07-17 16:31) [18]

← →
Sergey13 (2002-07-18 09:23) [19]

2Val © (17.07.02 11:47)
>у нее в таблице есть поле класс, значит таблица будет содержать >данные не по одному классу. А зачем отслеживать самому, если >есть средства для этого СУБД? Тут нужно смотреть на всю >таблицу, может еще что можно внести индекс.
Содержать она может что и сколько угодно. Но я никак не думал, что работать с такой таблицей будут в гриде по всем записям сразу. Гораздо проще предположить что с ней будут работать по классам(фильтры или запросы с where). В этом случае стоит ли огород городить, да еще с минимальным опытом работы с базами. Так можно и модуль проверки орфографии написать - вопрос нужно ли? ИМХО не надо стараться переложить на машину ВСЕ что можно.

2Galinka © (17.07.02 13:49)
Интересная у Вас школа. 8-)

Снова вопрос к мастерам. Нужна идея. Найти похожие ветки