|
Действия ...
Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
Новые сообщения [новые:0]
Дайджест
Горячие темы
Избранное [новые:0]
Форумы
Пользователи
Статистика
Статистика нагрузки
Мод. лог
Поиск
|
|
22.03.2005, 19:47
|
|||
|---|---|---|---|
Теоретический вопрос |
|||
|
#18+
У студента есть номер зачетки. Напрмер 023110 (моя). Как правило он используется в качестве внешнего ключа. Соответственно - атомарное значение Но вот возник геморой головного мозга: помимо номера зачётки в базе есть запись группа, факультет и год поступления. Но собственно номер зачётки содержит всё это: 0231 - Номер группы вообще. 2 - год поступления (2002). 3 - факультет. 1 - номер группы на потоке. Соответственно номер зачётки - не атомарное значение. И в качестве ключа использоваться не должно. Если добавить записи с факультетом, группой и иже с ними, то получим не нужную избыточность. Если добавим автоинкрементный id сделаем работу, которую уже сделал ректорат:) Если разбить номер зачётки типа вот: Код: plaintext 1. 2. А так ключь не атомарный использовать можно? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
22.03.2005, 21:22
|
|||
|---|---|---|---|
Теоретический вопрос |
|||
|
#18+
Давайте смотреть, какие есть варианты. 1. Суррогатный ключ плюс поле "номер зачетки" плюс дополнительные поля. Минус - избыточность; впрочем, для студентов это малопринципиально - максимум лишний десяток мегабайт. 2. Ключ из нескольких полей. Реальный геморрой всем, кто будет писать запросы на эту таблицу. 3. Использование номера зачетки как ключа плюс некоторое количество вычисляемых полей, расшифровывающих этот номер. Минус - обычный для такого подхода: а не будет ли "случая на миллион", когда сделанное предположение окажется неверным. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
22.03.2005, 21:52
|
|||
|---|---|---|---|
Теоретический вопрос |
|||
|
#18+
В принципе, что не читал, везде (в том числе вузовские учебники) номер зачётки - ключ внешний. Мне вот, что интересно: можно ФАКТИЧЕСКИ не атомарное значение хранить в реляцеонной базе? Можно неатомарное значение использовать в качестве ключа. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
22.03.2005, 22:17
|
|||
|---|---|---|---|
|
|||
Теоретический вопрос |
|||
|
#18+
> Мне вот, что интересно: можно ФАКТИЧЕСКИ не атомарное значение хранить в > реляцеонной базе? Можно. > Можно неатомарное значение использовать в качестве ключа. Можно. Если оно уникально. Встречный вопрос: зачем? Чем суррогатные ключи не устраивают? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
22.03.2005, 22:47
|
|||
|---|---|---|---|
Теоретический вопрос |
|||
|
#18+
Зачем изобретать велосепед? Ведь есть хороший ключь. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
23.03.2005, 01:27
|
|||
|---|---|---|---|
|
|||
Теоретический вопрос |
|||
|
#18+
> Ведь есть хороший ключь. Хороший ключ - суррогатный ключ. Потому как абсолютно независимый. Подумайте на досуге, какие потенциальные проблемы создаст Вам использование естественного ключа в описанном случае, если изменится алгоритм нумерации зачеток. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
23.03.2005, 08:02
|
|||
|---|---|---|---|
Теоретический вопрос |
|||
|
#18+
не говоря о том, что зачетку можно потерять, уйти в академ, изменить специальность (изменить факультет) и т.п.... и получится , что это уже другой студент ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
23.03.2005, 09:37
|
|||
|---|---|---|---|
Теоретический вопрос |
|||
|
#18+
SarinМне вот, что интересно: можно ФАКТИЧЕСКИ не атомарное значение хранить в реляцеонной базе? Фактически - можно, ИИ СУБД пока что не блокирует таких попыток :). Формально - надо понимать, почему теория настаивает на атомарных значениях; понимать недостатки этого подхода. Лично с моей точки зрения здесь слишком мелкий выигрыш, чтобы ради него отступать от теории и конструировать будущие проблемы. Ну, сэкономите Вы на студенте десять байт. Сколько их? Даже если с историей - 50.000 наберется? Итого сэкономите аж полмега диска и соответствующую долю оперативки и ввода-вывода. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
23.03.2005, 10:01
|
|||
|---|---|---|---|
Теоретический вопрос |
|||
|
#18+
2 Sarin. Однажды, в одном ВУЗе, студентам выдавались логины по номерам зачеток, и как то раз сверху спустили дублирующиеся номера зачеток. Столько нецензурной брани от сисадмина в тот день никто раньше никогда не слышал. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
23.03.2005, 23:24
|
|||
|---|---|---|---|
Теоретический вопрос |
|||
|
#18+
Насчёт атомарных значений слышал/читал. Они нужны, чтоб база была в 1НФ. Правильно? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
24.03.2005, 08:54
|
|||
|---|---|---|---|
Теоретический вопрос |
|||
|
#18+
SarinНасчёт атомарных значений слышал/читал. Они нужны, чтоб база была в 1НФ. 1НФ - не самоцель. Важно понимать, что они дают - или от чего придется отказаться. Во-первых, атомарные значения - требование, направленное на ликвидацию "перечисления в строке". В этой структуре такого не наблюдается. Во-вторых, атомарные значения гарантируют, что операции с ними пройдут "легко и просто". Лично я бы предпочел таки иметь независимые поля для года и остального - но если не хочется, существующие сегодня механизмы позволяют обеспечить это "легко и просто" без заметных проблем. Соответственно, в данном случае нет особых причин возражать против структуры "похожей на 3НФ, но с неатомарным значением". Возражения сводятся к естественным недостаткам естественных ключей. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
24.03.2005, 23:33
|
|||
|---|---|---|---|
Теоретический вопрос |
|||
|
#18+
softwarer SarinНасчёт атомарных значений слышал/читал. Они нужны, чтоб база была в 1НФ. 1НФ - не самоцель. Важно понимать, что они дают - или от чего придется отказаться. Во-первых, атомарные значения - требование, направленное на ликвидацию "перечисления в строке". В этой структуре такого не наблюдается. Во-вторых, атомарные значения гарантируют, что операции с ними пройдут "легко и просто". Лично я бы предпочел таки иметь независимые поля для года и остального - но если не хочется, существующие сегодня механизмы позволяют обеспечить это "легко и просто" без заметных проблем. Соответственно, в данном случае нет особых причин возражать против структуры "похожей на 3НФ, но с неатомарным значением". Возражения сводятся к естественным недостаткам естественных ключей. Самоцелью вроде является ликвидация возможности возникновения аномалий. Я серьёзные базы не лепил. Всё, что делал сразу получалось в 5НФ. Купил себе умную книжку. Там, кстати, в сетевых ресурсах sql.ry четвёртой строкой:) Читаю и внимаю. Мне очень интересну базы данных, а вуз не профильный. Вот и учусь по книгам, статьям да на форуме. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
25.03.2005, 12:45
|
|||
|---|---|---|---|
Теоретический вопрос |
|||
|
#18+
SarinСамоцелью вроде является ликвидация возможности возникновения аномалий. Именно. Возможность каких именно аномалий Вы видите в данном случае? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
25.03.2005, 13:45
|
|||
|---|---|---|---|
Теоретический вопрос |
|||
|
#18+
Вообще я боялся избыточности. Но наверное лучше будет сделать сурогатный ключь. Номер зачётки вообще исключить, а при необходимости генерить его на основании факультета, года поступления группы и т.д. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
25.03.2005, 14:04
|
|||
|---|---|---|---|
Теоретический вопрос |
|||
|
#18+
SarinВообще я боялся избыточности. Ее неприятные эффекты в данном случае легко устраняются. Например - триггером или вьюхой. Если же иметь в виду избыточность суррогатного ключа при наличии естественного - она сама по себе настолько минимальна и безобидна, что имеет смысл в основном в религиозных спорах. Sarin Но наверное лучше будет сделать сурогатный ключь. Это позволит убрать минусы естественного ключа. Поскольку Вы неопытны - это хорошая мысль; у суррогатного ключа нет "потенциальных будущих проблем". Sarin Номер зачётки вообще исключить, а при необходимости генерить его на основании факультета, года поступления группы и т.д. Может быть, именно так. Может быть, имеет смысл иметь альтернативный ключ; не так часто, но иногда удобно сослаться на таблицу не по первичному ключу. Генерить просто так, боюсь, не удастся - если нет какого-нибудь глупого понятия типа "номер студента в группе". ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
25.03.2005, 14:32
|
|||
|---|---|---|---|
Теоретический вопрос |
|||
|
#18+
Глупое понятие номер студента в группе как раз есть. Это две последнии цифры номера зачётки. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
25.03.2005, 14:41
|
|||
|---|---|---|---|
Теоретический вопрос |
|||
|
#18+
SarinГлупое понятие номер студента в группе как раз есть. Это две последнии цифры номера зачётки. Его нет как поля, которое имеет самостоятельный смысл. Полагаю, ни в какой ситуации от Вас не требуется ввести или вывести "номер студента в группе". Фактически Вам придется решить, иметь в таблице поле "номер зачетки" либо иметь в ней поле "номер студента в группе". Также стоит отметить, что само по себе объективно существующее понятие "номер студента в группе" может меняться после каждой сессии - что вряд ли соответствует номерам зачеток. Лично я выбрал бы "иметь номер зачетки". Сделав в интерфейсе его генерацию по указанным правилам. Потерь здесь - опять же считанные байты места. Преимущества - упрощение программы, а также устойчивость к коллизиям (например, студента перевели в другую группу - вряд ли ему при этом меняют зачетку). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
25.03.2005, 14:55
|
|||
|---|---|---|---|
Теоретический вопрос |
|||
|
#18+
Теоретически должны номер зачётки сменить. Ведь в другой группе есть студент с таким же номером_студента_в_группе. А он используется для определения варианта задачи на курсовик, или контрольную. И ещё много где. Избыточность в 25 байт на запись в общем не критична, как я понял. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
25.03.2005, 20:24
|
|||
|---|---|---|---|
|
|||
Теоретический вопрос |
|||
|
#18+
мдя... а кому вообще пришла в голову идея кодировать (номеровать) зачетки таким макаром и главное какова цель и идея такого кодирования? кино и немцы... про возможные коллизии в системе учета я уш и не говорю Sorry - не сдержался... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
25.03.2005, 20:34
|
|||
|---|---|---|---|
Теоретический вопрос |
|||
|
#18+
Веришь, не я это придумал. Вообще-то я не пишу сейчас ничего такого. Просто возник вопрос. Я, как уже говорил, на форуме учусь ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
25.03.2005, 20:48
|
|||
|---|---|---|---|
|
|||
Теоретический вопрос |
|||
|
#18+
SarinВеришь, не я это придумал. верю... никогда не используй в качестве ключа то, ты (или твое приложение) не контролируе(ешь/ет) - используй Autoincrement выданный ректоратом номер зачетки - это только условно-справочная (при таком раскладе) информация ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
26.03.2005, 11:50
|
|||
|---|---|---|---|
Теоретический вопрос |
|||
|
#18+
Sarinпомимо номера зачётки в базе есть запись группа, факультет и год поступления. Но собственно номер зачётки содержит всё это В корне неверное утверждение. В номере зачетки группа, специальность, год поступления, номер студент шифруются на момент выдачи зачетки. В дальнейшем они могут смениться, а номер зачетки - нет. Поэтому нельзя рассматривать номер зачетки как источник данных о студенте. Его следует трактовать как атомарный атрибут, значени которого кто-то где-то формирует по какому-то алгоритму. Но полагаться на "зашифрованные" в номере поля недопустимо. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
26.03.2005, 12:53
|
|||
|---|---|---|---|
Теоретический вопрос |
|||
|
#18+
SarinТеоретически должны номер зачётки сменить. Хм. Странно это :) По такой практике одна моя знакомая поменяла бы зачетку минимум три раза. А сколь помню - весь универ по одной отходила. И что-то мне подсказывает, что менять зачетку - большой бумажный геморрой. SarinВедь в другой группе есть студент с таким же номером_студента_в_группе. А он используется для определения варианта задачи на курсовик, или контрольную. И ещё много где. Ну и лафа у вас. То есть: все четные садятся справа, все нечетные - слева, и списывают :) SarinИзбыточность в 25 байт на запись в общем не критична, как я понял. Во-первых некритична - не то число записей. А во-вторых, что-то многовато байт получается - типа десятичной записи числа в юникоде :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
start [/forum/topic.php?fid=32&mobile=1&tid=1545966]: |
0ms |
get settings: |
6ms |
get forum list: |
14ms |
check forum access: |
2ms |
check topic access: |
2ms |
track hit: |
34ms |
get topic data: |
9ms |
get forum data: |
2ms |
get page messages: |
53ms |
get tp. blocked users: |
7ms |
| others: | 262ms |
| total: | 391ms |
| 0 / 0 |
