Создание хитрого генератора (помогите новичку)

Fed · Сообщение **Fed** » 13 ноя 2005, 10:52

Добого времени суток. Требуется заполнять поле первичного ключа следующим: DDMMYY~~~*** или DDMMYY***, где DD - текущий день, MM - месяц, YY - год, ~~~ - трехзначный код пользователя (за каждым пользователем закреплен свой код), *** - трехзначный счетчик (инкремент = 1). Можно и без ~~~, в принципе. Главное, чтоб дата бралась с сервера (!). Возможно, какую-то часть следует выполнять вне БД? Главное, как получить дату и привестиее в соответствующий вид. Прошу помочь, кто чем может. FB 1.5, FIBPlus, Delphi.

Ivan_Pisarevsky

Над первичным ключем так изголяться точно не стоит, а для не ключевого поля такой наворот вполне легко сформировать триггером или ХП.

Код: Выделить всё

select current_timestamp from rdb$database

дальше cast-ом выдергиваешь куски дататайма так как тебе надо и слепляешь в одну строку " || "

Fed · Сообщение **Fed** » 14 ноя 2005, 10:15

Спасибо. Только вот ты рекомендуешь не изголяться над первичным ключем. Думаешь лучше использовать обычный генератор (автоинкремент)? Дело в том что требуется именно такая иформативность этого поля. Чтоб знающие могли понять, когда и кем делалась запись. И еще вопрос не по теме. Можно-ли каким-то образом получить доступ к базе данных пользователей. (ведь это всего-лишь еще одна БД, пусть и служебная) (из SYSDBA, естественно). То есть, я к примеру, ввел запись на некоторого пользователя: LogIn (UserName) и FullName. Допустим, я в таблице для каждой записи в некотором поле храню UserName, сделавшего эту запись. Можно-ли в клиентском приложении подставлять вместо UserName, FullName? Просто одной строкой, есть ли какие-то особенности в обращении к этой БД, если кто сталкивался. (Сам еще не пробовал.)

Merlin · Сообщение **Merlin** » 14 ноя 2005, 11:42

Fed писал(а):Спасибо. Только вот ты рекомендуешь не изголяться над первичным ключем. Думаешь лучше использовать обычный генератор (автоинкремент)? Дело в том что требуется именно такая иформативность этого поля. Чтоб знающие могли понять, когда и кем делалась запись.

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

Fed · Сообщение **Fed** » 14 ноя 2005, 14:43

Глупый сарказм, Merlin. Это был лиш один из вариантов - база в зачаточной стадии. Кстати, предыдущая база, в организации, где я работал (сейчас уже нет), имела еще более худшую организацию ключевого поля. И ничего - работает уже десять лет, причем проблемы крайне редко возникающие с ней из-за этого (раз в 2 года может, и то это я чтоб не утверждать, что все совсем гут) неплохо перекрываются удобством эксплуатации и ремонта. В прежние времена это был неплохой выход, в отсутствии развитых средств лога. В этой стране, насколько я знаю всю документацию, в том числе и архивные копии базы требуется хранить на бумаге. Прикинь, сливаешь ты базу в архив, постепенно подчищаешь от уже неактуальных записей, а потом легко обратиться к "отложенному в сторонку" по вполне вполне системному, однозначному коду. Так что поле это я хоть и не стану делать ключевым, соглашусь, что это неправильно, но как одно из полей его все-же оставлю.

Merlin · Сообщение **Merlin** » 14 ноя 2005, 15:28

Fed писал(а):Глупый сарказм, Merlin.

Тебе виднее, как умеем, так и саркастируем.

Fed писал(а): потом легко обратиться к "отложенному в сторонку" по вполне вполне системному, однозначному коду.

А искать не по первичному ключу, а по атрибутам, если нужно, индексированным, - это не системно или просто не по-пацански? Почитал бы таки на досуге про нормальные формы всё-тки.

Fed писал(а): Так что поле это я хоть и не стану делать ключевым, соглашусь, что это неправильно, но как одно из полей его все-же оставлю.

Так кто был бы против. И автора-таймштамп не только первичной регистрации, но и последнего изменения тоже очень удобно держать в записи. В отдельных полях соответствующих типов, заполняемых триггерами на сервере. Вот только чем эти атрибуты (описатели свойств) записи, уникально идентифицируемой первичным ключом, отличаются от любых других её атрибутов, что их надо в ключи тащщыть?

Fed · Сообщение **Fed** » 15 ноя 2005, 07:52

Почитал бы таки на досуге про нормальные формы всё-тки.

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

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

Мне сейчас сложно привести пример, когда это удобно (несколько расширить информативность номера записи). Обычно это связано с обработкой информации БД вне самой базы (всякие там отчеты, не придусмотренные в качестве основных разработчиками системы). Это чисто психологический прием. Человеку гораздо проще запомнить информацию, наделенную смыслом. Информативный ключ (пусть на самом деле он ключем и не является, физически) - это как ссылка в мозгу рядового пользователя на конретную информацию. Это я давно заметил в работе с людьми, являющимися простыми пользователями базы данных.

Merlin · Сообщение **Merlin** » 15 ноя 2005, 12:32

Fed писал(а):
Почитал бы таки на досуге про нормальные формы всё-тки.
Выбор того или иного поля, однозначно определяющего запись в таблице, в качестве ключевого никак не связано с нормализацией. Это вопрос спорный и творческий.

Ясно. Значить, не читал и читать не буду.

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

Из той же оперы. Ключ, он же констрейнт - _ограничение_. И фсё. В случае первичного - уникальности. И пользователю об его существовании знать никакой надобности просто нету. Атрибуты, в том числе поисковые, играющие для пользователя психологическую роль идентификатора записи, к ключам никакого отношения не имеют и являются их описателями.

Ладно, bye. Чё меня дернуло ликбез проводить...

Ivan_Pisarevsky

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

Если б я такое изрек, когда сдавал зачет по теории баз данных, мне б точно влепили бы НЕУД

Я там выше написал про "cast" рука дрогнула, ток щас заметил, на самом деле там "extract" нужен

Чё меня дернуло ликбез проводить...

Видимо давно крайним не был

Fed · Сообщение **Fed** » 16 ноя 2005, 12:57

Если б я такое изрек, когда сдавал зачет по теории баз данных, мне б точно влепили бы НЕУД

Ну, это препод погорячился бы. Я имел ввиду, что если речь идет о двух полях, ОДНОЗНАЧНО определяющих запись, то с математической точки зрения не имеет никакого значения, какое из них я выбиру в качестве первичного ключа (Ограничение целостности ведь соблюдается и в том и вдругом случае.).
Это я так, отвлекся из-за Merlin-a.

Так что насчет базы данных пользователей? Идти открывать новый топик?

Ivan_Pisarevsky

Я имел ввиду, что если речь идет о двух полях, ОДНОЗНАЧНО определяющих запись

Схема изложенная в первом посте нифига уникальности не гарантирует: 1001 запись и кирдык

или юзер запускает 2-3 копии своей проги и снова кирдык

, а запуск 2 и более копий программы, например, для меня, явление совершенно штатное

Так что насчет базы данных пользователей?

Да мы тут где-то это уже перетирали, мож пару-тройку месяцев назад...

Fed · Сообщение **Fed** » 16 ноя 2005, 15:45

Схема изложенная в первом посте нифига уникальности не гарантирует: 1001 запись и кирдык или юзер запускает 2-3 копии своей проги и снова кирдык , а запуск 2 и более копий программы, например, для меня, явление совершенно штатное

Вот из-за таких вот "кердык" я и передумал. Хотя случай со 1001 записью в течении дня - космический случай, я его не рассматриваю. 999 - с головой в моем случае. А че толку одна или две копии программы запущено - не имеет значения. Сервер ведь обрабатывает запрос на добавление записи, и в данном случае не имеет значения из какой копии программы производился запуск. Или я чего-то не понимаю?

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

Спасибо за помощь, пошел искать.

Ivan_Pisarevsky

А че толку одна или две копии программы запущено - не имеет значения. Сервер ведь обрабатывает запрос на добавление записи, и в данном случае не имеет значения из какой копии программы производился запуск. Или я чего-то не понимаю?

А это чье?

~~~ - трехзначный код пользователя (за каждым пользователем закреплен свой код)

Я раз зашел мои "123" есть, второй раз снова "123" теперь из обоих копий вношу по записи и привет... нарушение уникальности первичного ключа.

Fed · Сообщение **Fed** » 17 ноя 2005, 03:54

Я раз зашел мои "123" есть, второй раз снова "123" теперь из обоих копий вношу по записи и привет... нарушение уникальности первичного ключа.

Смотри далее ->

*** - трехзначный счетчик (инкремент = 1)

Вот именно он и изменяется при добавлении. Впрочем это уже не важно.

SAMZ · Сообщение **SAMZ** » 17 ноя 2005, 12:12

Fed писал(а):
Я раз зашел мои "123" есть, второй раз снова "123" теперь из обоих копий вношу по записи и привет... нарушение уникальности первичного ключа.
Смотри далее ->

*** - трехзначный счетчик (инкремент = 1)
Вот именно он и изменяется при добавлении. Впрочем это уже не важно. :o

Уважаемый FED!
Уверяю тебя, что советы тебе давали очень знающие люди, прислушайся.
В любом случае при создании новой табицы в 99 случаях из 100 начинай с создания целочисленного поля - первичного ключа, нисколько не заботясь о восприятии зтого поля конечным пользователем БД. Он (пользователь) в подавляющем большинстве случаев и знать ничего о нем не будет.

Fed · Сообщение **Fed** » 18 ноя 2005, 11:10

Да я и не спорю. Так и делаю. Просто дискуссия возникла... Спасибо.