Главная страница
    Top.Mail.Ru    Яндекс.Метрика
Форум: "Базы";
Текущий архив: 2002.08.08;
Скачать: [xml.tar.bz2];

Вниз

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

 
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]

> MsGuns ©
> Evgeny7
Спасибо, я получила письмо. Дома буду разбираться.




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

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

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



Страницы: 1 вся ветка

Форум: "Базы";
Текущий архив: 2002.08.08;
Скачать: [xml.tar.bz2];

Наверх





Память: 0.5 MB
Время: 0.007 c
4-24261
AlexanderSK
2002-05-24 15:36
2002.08.08
Глупый вопрос! Но...


3-23944
Explorer
2002-07-18 14:55
2002.08.08
Как из StringGrid вставить данные в БД(MSSQL)?


3-23885
First_May
2002-07-16 10:11
2002.08.08
Прерывание запроса


14-24231
BlackGrin
2002-07-13 01:26
2002.08.08
Ищу иходник


1-24006
Faun
2002-07-28 07:09
2002.08.08
CreateParented и скроллинг





Afrikaans Albanian Arabic Armenian Azerbaijani Basque Belarusian Bulgarian Catalan Chinese (Simplified) Chinese (Traditional) Croatian Czech Danish Dutch English Estonian Filipino Finnish French
Galician Georgian German Greek Haitian Creole Hebrew Hindi Hungarian Icelandic Indonesian Irish Italian Japanese Korean Latvian Lithuanian Macedonian Malay Maltese Norwegian
Persian Polish Portuguese Romanian Russian Serbian Slovak Slovenian Spanish Swahili Swedish Thai Turkish Ukrainian Urdu Vietnamese Welsh Yiddish Bengali Bosnian
Cebuano Esperanto Gujarati Hausa Hmong Igbo Javanese Kannada Khmer Lao Latin Maori Marathi Mongolian Nepali Punjabi Somali Tamil Telugu Yoruba
Zulu
Английский Французский Немецкий Итальянский Португальский Русский Испанский