Сделать bibcode - primary key для связи библиографии с данными

[dimakarov]

В настоящее время структура библиографии имеет два ключевых поля
id PRIMARY KEY - предназначено для связи между библиографией и данными
bibcode UNIQUE - предназначено для связи с ADS & CDS

id генерируется автоматически
bibcode обязан (в идеале) указывать на реальную библиографию во внешней БД

Текущая схема позволяет не беспокоиться об уникальности идентификатора для библиографии и создавать свои собственные записи, не привязанные к ADS. Например, обработка приватных сообщений, работа над кроссидентификацией объектов, решение запутанных ситуаций с данными, свои собственные проекты, такие как работа над Местным Объемом, создание каталогов и т.п. При этом, bibcode отвечает только за "внешние связи".

Чисто технически, нет большой сложности объединить id и bibcode в один ключ, который будет нести в себе как связь с данными в Леда, так и связь с ADS.

На данный момент, я вижу не очень много плюсов от этого:

1. в таблице rawdata.tables поле bib будет содержать bibcode в явном виде (это легко решается созданием представления связывающего данные с библиографией)
2. немного упрощается структура библиографии
3. количество наших персональных работ будет несоизмеримо меньше литературных данных, поэтому уникальность id и bibcode дублирует друг друга

Минусы, которые я вижу от отказа от числового автогенерируемого id:

1. нам нужно будет каким-то образом поддерживать генерацию уникального ключа-строки для поля поля bibcode
2. перед обращением к ADS проверять, что bibcode соответствует формату и есть шанс получить оттуда данные
3. один ключ получается нагружен двумя функциями связи данных и связи с внешней БД
4. разные релизы внешних баз данных, откуда мы планируем брать данные, может быть не обеспечена соответствующими публикациями, как это делается в обзоре SDSS.
   1. Как пример, база данных EDD. В ней идет планомерное накопление или переобработка данных, а публикация была выпущена довольно давно. Логично было бы иметь уникальную запись в библиографии, соответствующую дате забора данных, а библиография будет указывать на "устаревшую" статью. В этом случае, вероятно, будет необходимо отказаться от уникальности bibcode.
   2. Еще один пример - обзор ALFALFA. Финальная версия каталога отличается от версии в последней опубликованной статье. На мой взгляд, имело бы смысл использовать самую самую последнюю версию таблицы, но со ссылкой на финальную статью. Опять же bibcode теряет свою уникальность.
   3. Похожая ситуация может сложиться с другими базами данных, типа RCSED2, где релизы могут быть не сопровождены статьями.

На данный момент, я бы сказал, что склоняюсь к мысли, что надо оставить оба ключа как есть. Т.е. id для связи данных и библиографии в нашей БД, и bibcode - для связи с ADS.

[Kraysent]

Немного контекста, почему этот вопрос вообще возник:

Мне хочется сделать интерфейс загрузки данных наиболее простым для подавляющего большинства случаев. В моей голове самый типичный процесс загрузки данных выглядит следующим образом:

1. Создать таблицу, ассоциированную с некоторой опубликованной статьёй.
2. Загрузить туда данные.

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

Пока что создание таблицы из пункта 1 выше выглядит следующим образом:

1. Создать запись в библиографии с bibcode, получить наш внутренний уникальный численный id этой записи.
2. Создать таблицу, ссылающуюся на него.

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

Для отдельных случаев, когда, например, данные получены из внутренней коммуникации, можно сделать отдельный метод API для создания записи в библиографии об этой внутренней коммуникации. Главное, чтобы для самого базового сценария, когда bibcode всё же есть, не приходилось знать об этом методе и можно было пользоваться только методом создания таблицы напрямую.

Учитывая плюсы и минусы из комментария выше, предлагаю среднее решение:

• Оставить id первичным ключом, как есть сейчас - он останется для связи данных внутри Leda.
• Поле bibcode переименовать на code (код статьи, который её идентифицирует вне Leda) и снять с него ограничения на регулярное выражение и длину.
• В этот код для опубликованных статей записывать bibcode, так же как сейчас, а для внутренних коммуникаций - созданный отдельным методом API идентификатор. Мне бы хотелось чтобы этот идентификатор обладал следующими свойствами:
  • Был более или менее человекочитаемым - из него хотелось бы уметь понимать год, и, быть может, инициалы автора. Опционально - название/первые буквы названия заголовка этой внутренней коммуникации.
  • Был отличен по виду от bibcode - чтобы у нас был алгоритм, по которому по виду идентификатора можно понять, пришёл он из ADS или из внутренней коммуникации.

Этот идентификатор не обязательно делать длинным. Можно, например, сделать что-то следующее: AAAAAYYYYTTTTTT, где AAAAA - первые 5 букв фамилии первого автора, YYYY - четырёхзначный год, TTTTTTT - первые 6 букв заголовка коммуникации без пробелов и спецсимволов. Этот формат не фиксированный, можно обсудить подробнее, как лучше сделать.

Такое решение уберёт проблему, описанную в минусах 3 и 4 в комментарии выше. Минус номер 2 мне видится неизбежным - нам в любом случае приходится иметь какой-то алгоритм, по которому для опубликованных статей идти в ADS за данными о заголовке, авторе и годе, а для внутренних коммуникаций - нет. Сейчас это простая проверка, что нам прислали NULL в поле bibcode создания библиографии, но этим мы упрощаем жизнь себе за счёт усложнения её пользователю - он должен знать, что если bibcode не передан, то нужно обязательно передать title, author и year, и наоборот - если bibcode передан, то мы проигнорируем остальные поля. В итоге остаётся минус номер 1, но мне кажется, что это не очень большая цена за упрощение интерфейса взаимодействия с Leda, особенно если сделать алгоритм совсем не сложным, как выше.

Это позволит в методе API на создание таблицы сделать одно-единственное поле code, в которое пользователь будет передавать по умолчанию всегда bibcode, но при необходимости может передать наш идентификатор. Далее, уже в коде метода, мы будем делать примерно следующее:

• Если присланный code удовлетворяет регулярному выражению на bibcode, мы сходим в ADS, получим оттуда заголовок, список авторов и год и сделаем новую запись в базе (или не сделаем, если по этому bibcode уже есть запись).
• Если присланный code удовлетворяет регулярному выражению на наш идентификатор, то мы знаем, что пользователь до этого вызвал метод на создание записи библиографии для внутренней коммуникации, и мы просто проверяем, что в таблице bib есть запись, в которой поле code равен присланному.

Для того, чтобы алгоритм выше мог работать, нам надо, чтобы по регулярному выражению можно было отличить наш внутренний идентификатор от bibcode.