Дорогой хабр, мне, кажется, нужен совет хорошего DBA. Или хорошего архитектора. Или вообще кого-нибудь.
Дело в том, что в одной французской деревушке этим летом уходит на пенсию программист. И все бы ничего, но программист этот 15 лет назад написал и до сего момента поддерживал базу данных каталогов двойных звезд (непосредственно около деревушки располагается обсерватория). Теперь эта база данных по какому-то договору о взаимном сотрудничестве переедет в наш институт, где и будет дальше поддерживаться. Скорее всего, поддерживаться мной.
Как показало внимательное изучение, программа эта представляет сейчас, скорее, музейный интерес и в таком виде помещать ее на наш сервер нельзя. Это набор CGI-скриптов на csh, выбирающих данные из текстовых файлов эпических размеров. Широко используется awk, sed, а также французский язык в тех местах, где awk и sed недостаточно. В общем, речь идет сейчас о практически полном переписывании всего с нуля, с использованием SQL и каких-нибудь языков программирования, не будем заострять на них внимание.
Вопрос в следующем: как грамотно перенести на SQL следующую структуру данных:
База данных состоит из:
Каталогов. Ориентировочное число — два-три десятка. Возможно добавление новых. Каталоги либо неизменны, либо обновляются целиком. Каждый каталог — таблица с десятком-другим полей. Также каталог может содержать наборы файлов (скажем — кривые блеска), с именами, ссылки на которые есть в таблице. В каждом каталоге содержатся разные поля, наборы полей пересекаются слабо. Поиск в данный момент происходит только по идентификаторам (именам) компонент, но в будущем планируется еще поиск по определенному набору параметров, каждый параметр, в общем случае, функция от нескольких полей. Скажем, надо будет найти все звезды в определенном радиусе вокруг точки на небесной сфере, или, скажем, все звезды типа T Tau, с периодами <10 дней.
Каждая запись в каталоге соответствует либо объекту — компоненту двойной (или кратной) звезды, таких каталогов меньшинство, либо паре — двойной звезде. Для некоторых двойных звезд есть информация только об одном компоненте и, скажем, о орбитальном периоде. Просто второй компонент не виден. Звезды могут быть не только двойными, но и кратными. Чаще всего, кратная звезда разбивается на набор двойных (в разных каталогах это может быть сделано по разному). По запросу надо будет находить все компоненты кратной системы. Число записей в каталогах различно и варьируется от нескольких десятков до сотен тысяч.
Кроме того, существуют таблицы кросс-идентификации, созданные частично вручную, разными авторами, местами противоречащие друг другу. Они определяют соответствие друг другу записей в разных каталогах.
В итоге, нужно, чтобы по запросу (по идентификатору или параметрам) пользователь получал всю доступную информацию, хранящуюся в каталогах. Причем не только по запрошенным объектам/парам, но и по другим компонентам двойной/кратной системы, куда запрошенные объекты входят, если таковые имеются.
Внимение, вопрос: Как грамотно разбросать столь разнородные данные по таблицам, чтобы добавление новых каталогов не требовало изменения структуры таблиц а поиск и выборка были достаточно быстрыми?
С наскока решить эту задачу у меня не получилось, тем более, что по образованию я, скорее, физик, чем DBA :)
Дело в том, что в одной французской деревушке этим летом уходит на пенсию программист. И все бы ничего, но программист этот 15 лет назад написал и до сего момента поддерживал базу данных каталогов двойных звезд (непосредственно около деревушки располагается обсерватория). Теперь эта база данных по какому-то договору о взаимном сотрудничестве переедет в наш институт, где и будет дальше поддерживаться. Скорее всего, поддерживаться мной.
Как показало внимательное изучение, программа эта представляет сейчас, скорее, музейный интерес и в таком виде помещать ее на наш сервер нельзя. Это набор CGI-скриптов на csh, выбирающих данные из текстовых файлов эпических размеров. Широко используется awk, sed, а также французский язык в тех местах, где awk и sed недостаточно. В общем, речь идет сейчас о практически полном переписывании всего с нуля, с использованием SQL и каких-нибудь языков программирования, не будем заострять на них внимание.
Вопрос в следующем: как грамотно перенести на SQL следующую структуру данных:
База данных состоит из:
Каталогов. Ориентировочное число — два-три десятка. Возможно добавление новых. Каталоги либо неизменны, либо обновляются целиком. Каждый каталог — таблица с десятком-другим полей. Также каталог может содержать наборы файлов (скажем — кривые блеска), с именами, ссылки на которые есть в таблице. В каждом каталоге содержатся разные поля, наборы полей пересекаются слабо. Поиск в данный момент происходит только по идентификаторам (именам) компонент, но в будущем планируется еще поиск по определенному набору параметров, каждый параметр, в общем случае, функция от нескольких полей. Скажем, надо будет найти все звезды в определенном радиусе вокруг точки на небесной сфере, или, скажем, все звезды типа T Tau, с периодами <10 дней.
Каждая запись в каталоге соответствует либо объекту — компоненту двойной (или кратной) звезды, таких каталогов меньшинство, либо паре — двойной звезде. Для некоторых двойных звезд есть информация только об одном компоненте и, скажем, о орбитальном периоде. Просто второй компонент не виден. Звезды могут быть не только двойными, но и кратными. Чаще всего, кратная звезда разбивается на набор двойных (в разных каталогах это может быть сделано по разному). По запросу надо будет находить все компоненты кратной системы. Число записей в каталогах различно и варьируется от нескольких десятков до сотен тысяч.
Кроме того, существуют таблицы кросс-идентификации, созданные частично вручную, разными авторами, местами противоречащие друг другу. Они определяют соответствие друг другу записей в разных каталогах.
В итоге, нужно, чтобы по запросу (по идентификатору или параметрам) пользователь получал всю доступную информацию, хранящуюся в каталогах. Причем не только по запрошенным объектам/парам, но и по другим компонентам двойной/кратной системы, куда запрошенные объекты входят, если таковые имеются.
Внимение, вопрос: Как грамотно разбросать столь разнородные данные по таблицам, чтобы добавление новых каталогов не требовало изменения структуры таблиц а поиск и выборка были достаточно быстрыми?
С наскока решить эту задачу у меня не получилось, тем более, что по образованию я, скорее, физик, чем DBA :)