От SK
К All
Дата 11.09.2006 11:55:23
Рубрики Прочее; Люди и авиация; Авиатехника;

База данных

Приветствую уважаемых коллег!
Хотел бы обратиься со следующей просьбой. Сейчас многие из нас создают различные базы данных (по потерям, по погибшим и т.д.) Я делаю свою по самолетам Як.
В каком формате лучше всего делать базу, чтобы потом не пришлось со слезами на глазах перебивать все вручную (должна быть обеспечена возможность слияния баз данных).
Второй вопрос, что необходимо бы включить в базу по самолетам кроме:
типа, модификации;
дат изготовления, приемки, потери, списания;
серийного номера и завода изготовителя;
мотора(ов) с № и на какую дату стоял на самолете;
Движения самолета по полкам (прибыл, откуда, убыл, куда, источник, или дата и причина потери);
состав вооружения и оборудования (просто какой из нескольких варантов или еще нужны номера);
налет до потери;
примечание.
Надеюсь на помощь.
СК
От Seeker
К SK (11.09.2006 11:55:23)
Дата 12.09.2006 21:45:24

Давайте закругляться.

Обсуждать детали можно еще долго, однако хочу подвести итоги (для себя) и поставить вопросы:

1. Полезность такой БД никто не отрицает, все "за", хотя и имеются оговорки.
2. На общественных началах создание такой базы нам не потянуть, даже если среди присутствующих имеются приличные программеры, могущие (а главное, желающие) этим заняться.
3. Из вышесказанного вытекает мысль - надо привлечь к разработке профессионалов, которым надо будет платить. И довольно прилично - и за разработку и сопровождение. Зато они, матерясь на идиотов-заказчиков, в поте лица будут отлавливать баги и к которым следует предьявлять претензии по работе программы и пожелания о модификации.
4. Далее, для плодотворной работы программеров (неважно, нанятых или энтузиастов) необходимо выработать определенные требования, ТТЗ, к БД. Из чего следует, что нужен какой-то орг. комитет который всем этим займется, в том числе и обсуждением экономических и юридических аспектов (обсуждение лучше вести не на форуме). Добровольцы есть? Нет, что и следовало ожидать.
5. При выработке ТТЗ необходимо, в первую очередь, учесть не то, что вы хотите в ней видеть, а ЧТО можно найти, какими источниками придется пользоваться. Ну, и конечно, целесообразность наличия тех или иных моментов.
6. Основа БД - человек, который:
а) родился/умер
б) служил - и пошла доп. БД по частям.
в) воевал - пошла БД по боевой работе, а там и БД по событиям/потерям/победам в деталях и т.п, еще чего-нибудь подтянется.
г) летал на - пошла БД по конкретному самолету, а он, в свою очередь, связан с БД по еропланам (производство, модификации и т.п.)
д) награжден - пошла БД по наградам.
е) все увязывается БД по источникам.
ж) продолжение следует...

Как видим, при такой схеме многие БД можно использовать (и вести) автономно.

Однако, если это процесс будет пущен на самотек, толку не будет.
От Василий
К Seeker (12.09.2006 21:45:24)
Дата 13.09.2006 16:30:39

Re: Давайте закругляться.

>1. Полезность такой БД никто не отрицает, все "за", хотя и имеются оговорки.

Вот как раз оговорки и приведут к тому, что всеобъемлющей базы не получится:
1. отвергаю саму мысль о том, чтобы дать возможность добавлять/исправлять данные в БД всем кому не лень. В итоге получим массу недостоверной информации. Т.е. право вносить изменения должно быть у небольшого коллектива администраторов.
2. сомневаюсь, что все, кто уже имеют наработки - отдадут их в общую копилку, т.к. потратили массу своего времени, нервов и денег. А это значит, что очень многое очередным энтузиастам прийдется делать заново (в т.ч. перелопачивать фонды архивов).
3. уже говорилось, что многие имеют свои базы данных. Кто-то все-таки отдаст свои наработки. И вот тут начнется мучительный процесс слияния баз. Даже если эти базы сделаны в одном формате, будет различаться структура данных. Например, у одного ФИО занесены пораздельно в трех полях, а у другого в одно. Даты где-то в стандартном формате, а где-то в текстовом виде: 41.06.22, 41.06 или 41.06к (то бишь, конец июня). Да мало ли различий в форме представления данных. Вот и получится, что автоматизировать процесс слияния баз не получится! Всё надо будет делать ручками. Отдельная проблема - отловить повторы. Т.е. администраторам нужно будет приложить массу усилий, чтобы перетащить уже готовые массивы информации в общую БД.
4. есть закономерность: "всем не угодишь". Поэтому для каждого отдельно взятого пользователя в базе будет масса лишнего, в то же время не будет чего-то жизненно важного. А отсюда всплывает коммерческая сторона: платить за всю базу или же решить вопрос о возможности распространения/доступа лишь к части базы за меньшие деньги.

Ну и мое ИМХО:
База глобального масштаба (люди + техника + авиачасти/соединения + боевые действия + еще много, да еще и за период с момента появления первого воздушного змея) без финансирования большого рабочего коллектива - заведомо провальный вариант. Уж простите меня за такой пессимизм :((

Более реально делать так: есть наработки в любом виде и их не жалко отдать - публикуйте в интернете. Хочется денежку срубить - публикуйте в виде книг или предложите желающим купить на диске.

С уважением,
Василий.
От Василий Т.
К Василий (13.09.2006 16:30:39)
Дата 16.09.2006 08:14:43

Re: Давайте закругляться.

Доброе время суток!

>3. уже говорилось, что многие имеют свои базы данных. Кто-то все-таки отдаст свои наработки. И вот тут начнется мучительный процесс слияния баз. Даже если эти базы сделаны в одном формате, будет различаться структура данных. Например, у одного ФИО занесены пораздельно в трех полях, а у другого в одно. Даты где-то в стандартном формате, а где-то в текстовом виде: 41.06.22, 41.06 или 41.06к (то бишь, конец июня). Да мало ли различий в форме представления данных. Вот и получится, что автоматизировать процесс слияния баз не получится! Всё надо будет делать ручками.

Не совсем так. Этот процесс автоматизируется, если из различных БД организовать сброс данных в наиболее доступной форме - например, текстовый файл установленного формата. А перенести из текстового файла в обобщенную БД уже совсем никаких проблем не составляет.
(Для справки. Подобный метод был использован при перевода складской информации одного из заводов с машины серии ЕС на сеть "персоналок".)

>Отдельная проблема - отловить повторы.

А вот это проблема. Но и она решаема, т. к. после переноса все равно потребуется сверка обобщенной базы данных с источниками.

С уважением, Василий Т. http://ww2doc.50megs.com/Issues.html
От SK
К Василий Т. (16.09.2006 08:14:43)
Дата 16.09.2006 11:54:23

Re: Давайте закругляться.

>Доброе время суток!

>>3. уже говорилось, что многие имеют свои базы данных. Кто-то все-таки отдаст свои наработки. И вот тут начнется мучительный процесс слияния баз. Даже если эти базы сделаны в одном формате, будет различаться структура данных. Например, у одного ФИО занесены пораздельно в трех полях, а у другого в одно. Даты где-то в стандартном формате, а где-то в текстовом виде: 41.06.22, 41.06 или 41.06к (то бишь, конец июня). Да мало ли различий в форме представления данных. Вот и получится, что автоматизировать процесс слияния баз не получится! Всё надо будет делать ручками.
>
>Не совсем так. Этот процесс автоматизируется, если из различных БД организовать сброс данных в наиболее доступной форме - например, текстовый файл установленного формата. А перенести из текстового файла в обобщенную БД уже совсем никаких проблем не составляет.
>(Для справки. Подобный метод был использован при перевода складской информации одного из заводов с машины серии ЕС на сеть "персоналок".)
Совсем не обязательно все делать через текст. При переводе в dbf файл можно программно задать правила конвертации. И соответственно все
06н перенесутся, например, в два поля дата начала периода 1.6. и дата конца периода 15.6.
СК
От timsz
К SK (16.09.2006 11:54:23)
Дата 17.09.2006 00:53:31

Re: Давайте закругляться.

Но это для этого сначала надо перевести свою информацию в dbf. Что может оказаться совсем не просто (не у всех на машине есть access, да и требует минимальных знаний о СУБД).

Да и даже при конвертации access-access или excel-excel иногда возникают такие проблемы, что проще сначала в csv перевести. Особенно со всякими русскими кодировками.
От Seeker
К Василий (13.09.2006 16:30:39)
Дата 13.09.2006 21:36:38

Re: Давайте закругляться.


>Вот как раз оговорки

пока что все оговорки сводятсяк "нафига козе баян".

>1. отвергаю саму мысль о том, чтобы дать возможность добавлять/исправлять данные в БД всем кому не лень.

Ну, это понятное дело. Вообще то этим займутся специально обученные люди.


>2. сомневаюсь, что все, кто уже имеют наработки

Решаемо. Но, при отсутствии самого механизма функционирования такой БД, не имеет смысла обсуждать. "Решаем проблемы по мере поступления".

>3. ... И вот тут начнется мучительный процесс слияния баз. Даже если эти базы сделаны в одном формате, будет различаться структура данных.

Нет препятствий технического плана, все решаемо.

>4. есть закономерность: "всем не угодишь". Поэтому для каждого отдельно взятого пользователя в базе будет масса лишнего, в то же время не будет чего-то жизненно важного. А отсюда всплывает коммерческая сторона: платить за всю базу или же решить вопрос о возможности распространения/доступа лишь к части базы за меньшие деньги.

Продолжаем обсуждать "сферических коней в ваккуме". Платится за доступ к БД, а о чем Вы будете запрашивать - сколько Яков было вооружено ШКАСАМи, какие боеприпасы поставлялись в Н-ский полк накануне 31 декабря, или соотношение пленных к расстрелянным и т.п. - значение не имеет.


>База глобального масштаба (люди + техника + авиачасти/соединения + боевые действия + еще много, да еще и за период с момента появления первого воздушного змея) без финансирования большого рабочего коллектива - заведомо провальный вариант.

Не совсем так - есть костяк/ствол БД, это человек, от него пойдут ответвления в виде отдельных (временами совершенно самостоятельных), дочерних БД по самолетам, моторам, частям, наградам, событиям, потерям и т.п. Можно добавлять новые ветки, отсекать ненужные и т.п. Т.е., можно все делать последовательно/параллельно с основной БД. Но это не любительский уровень, поэтому нужно: а) инициативная группа заказчиков-разработчиков; б) группа профессиональных разаработчиков СУБД, которым нужно денюжку платить.

>Более реально делать так: есть наработки в любом виде и их не жалко отдать - публикуйте в интернете. Хочется денежку срубить - публикуйте в виде книг или предложите желающим купить на диске.

И Вы туда же. Нет ничего, даже наметок, а уже деньги делить, а-яй-яй. :))

З.Ы. Статья о Уэйке Ваша?
От Василий
К Seeker (13.09.2006 21:36:38)
Дата 14.09.2006 20:56:38

Re: Давайте закругляться.

>>Более реально делать так: есть наработки в любом виде и их не жалко отдать - публикуйте в интернете. Хочется денежку срубить - публикуйте в виде книг или предложите желающим купить на диске.
>
>И Вы туда же. Нет ничего, даже наметок, а уже деньги делить, а-яй-яй. :))

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

>З.Ы. Статья о Уэйке Ваша?
А кто такой Уэйк? (чесслово, не знаю)
От Katz
К Seeker (13.09.2006 21:36:38)
Дата 14.09.2006 10:41:35

Re: Давайте закругляться.

>И Вы туда же. Нет ничего, даже наметок, а уже деньги делить, а-яй-яй. :))

Шутник ты батенька. У Василия нет нароботок? ДЫк у него База своя дай Бог каждому
От Seeker
К Katz (14.09.2006 10:41:35)
Дата 14.09.2006 11:11:04

Неправильно поняли.


>Шутник ты батенька. У Василия нет нароботок? ДЫк у него База своя дай Бог каждому

Речь идет о гиптетической БД, а не о том, у кого какие наработки имеются.
От Василий
К Seeker (14.09.2006 11:11:04)
Дата 14.09.2006 21:10:00

Re: Неправильно поняли.

>Речь идет о гиптетической БД, а не о том, у кого какие наработки имеются.

А я как раз о наработках: не сможет ограниченный коллектив энтузиастов-администраторов заполнить (заметьте: не создать базу, а заполнить) гипотетическую базу, если те, кто имеет наработки, не поделятся ими. Ведь данные для базы откуда-то взять надо!
От timsz
К Seeker (12.09.2006 21:45:24)
Дата 13.09.2006 09:34:09

В базе главное - наполнение. Программирование - дело второе. (-)
От SK
К timsz (13.09.2006 09:34:09)
Дата 13.09.2006 11:17:08

Re: В базе...

По роду своего основного занятия мне приходится иметь дело как с администрированием баз данных (бухгалтерских), так и с работой в них и с их доработкой.
Различных работ разных программерских коллективов хватает на этом рынке. Однако некоторые статичны (обычно это ДОСовские программы) и не поддаются большой доработке, а некоторые гибки (как 1С), которую можно легко дорабатывать. Да и удобство работы с этими БД разное. В первых, чтобы войти в другой документ (страничку БД) нужно закрыть тот, в котором ты сейчас находишься. А во вторых можно свободно "плавать" от документов к сводным отчетам и базам данных.
Удобство пользования обеспечивается как раз программно.
СК
От timsz
К SK (13.09.2006 11:17:08)
Дата 13.09.2006 12:19:53

Так надо делать на чем-то удобном. На том же Access'е, например.

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

Мне по-прежнему кажется, что наиболее удобный движок - XML. Там вообще все в текстовом виде, каждый может просто открыть Блокнот и заполнить, хотя есть и удобные утилиты. Кроме того, сейчас и Word, и Excel его поддерживают, только я еще не разобрался насколько это удобно.
От Seeker
К timsz (13.09.2006 09:34:09)
Дата 13.09.2006 11:00:40

Ну-ну... Попробуйте хотя бы одну базу написать, потом и говорите. (-)
От timsz
К Seeker (13.09.2006 11:00:40)
Дата 13.09.2006 12:10:30

А в чем проблемы? Берется access...

До access'а был Paradox.
От SK
К timsz (13.09.2006 12:10:30)
Дата 13.09.2006 15:40:30

Re: А в

В том-то и дело, что эта программа мягко говоря неповоротливая. Чтобы создать какую-то выборку (например все боевые эпизоды с участем АИП) нужно лезть в заранее составленный запрос и через конструктор!!! объяснять базе чего ты хочешь и в каком виде получить.
Далее, возможности сортировки таблиц довольно ограничены. Беру простой пример - серийные номера машин. Чтобы связать всю базу они являются уникальными. Соответственно серийным номерам Як-1 301 завода следует придумать какое-то другое обозначение т.к. есть совпадения с серийниками машин 292 завода. Далее сортировщик воспринимает серийный номер как единое целое и объяснить ему сирому, что это две-три цифры с хвоста или с начала не представляется возможным.
Для примера бросил в копилку базу по литературе в оной проге. Кто хочет попробуйте поистязать ее на досуге.
СК
От amyatishkin
К SK (13.09.2006 15:40:30)
Дата 18.09.2006 07:06:26

Re: А в

>В том-то и дело, что эта программа мягко говоря неповоротливая. Чтобы создать какую-то выборку (например все боевые эпизоды с участем АИП) нужно лезть в заранее составленный запрос и через конструктор!!! объяснять базе чего ты хочешь и в каком виде получить.
>Далее, возможности сортировки таблиц довольно ограничены. Беру простой пример - серийные номера машин. Чтобы связать всю базу они являются уникальными. Соответственно серийным номерам Як-1 301 завода следует придумать какое-то другое обозначение т.к. есть совпадения с серийниками машин 292 завода. Далее сортировщик воспринимает серийный номер как единое целое и объяснить ему сирому, что это две-три цифры с хвоста или с начала не представляется возможным.
>Для примера бросил в копилку базу по литературе в оной проге. Кто хочет попробуйте поистязать ее на досуге.
>СК

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

В принципе как раз аксесовские базы довольно живучие при падениях - Билли себе гадить не будет.

Варинаты бэкапа тоже можно продумать исходя из размеров базы.

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

Правда, я нафиг аксес забросил несколько лет назад, и все ненужное позабыл, а вот базы еще живут без присмотра.
От timsz
К SK (13.09.2006 15:40:30)
Дата 13.09.2006 15:56:38

Тут не в Аксессе дело, а в сложности входных данных.

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

Чудес не бывает - со сложной базой нельзя работать просто.
От SK
К timsz (13.09.2006 15:56:38)
Дата 13.09.2006 16:11:48

Re: Тут не...

>Чудес не бывает - со сложной базой нельзя работать просто.
Можно и нужно. В простейший штатный отчет базы включается возможность выбора записей по фильтрам. Например:
- дата или период;
- часть (подразделение соединение и т.д.) по умолчанию все;
- тип самолета - по умолчанию все.
А дальше жмем ОК и получаем отчет(ы), например:
летчики
потери
победы
награждения
базирование
состав м/ч
ранения, и т.д.
Времени занимает не более минуты. И все сортируется как вы того пожелаете. Далее смотрите в документ в ваших руках и сравниваете (анализируете) информацию, полученную из БД. Вносите коррекцию или дополнение в базу.
Все.
СК
От timsz
К SK (13.09.2006 16:11:48)
Дата 13.09.2006 16:33:24

Re: Тут не...

>Можно и нужно. В простейший штатный отчет базы включается возможность выбора записей по фильтрам. Например:
>- дата или период;
>- часть (подразделение соединение и т.д.) по умолчанию все;
>- тип самолета - по умолчанию все.
>А дальше жмем ОК и получаем отчет(ы), например:
>летчики
>потери
>победы
>награждения
>базирование
>состав м/ч
>ранения, и т.д.
>Времени занимает не более минуты. И все сортируется как вы того пожелаете. Далее смотрите в документ в ваших руках и сравниваете (анализируете) информацию, полученную из БД. Вносите коррекцию или дополнение в базу.
>Все.
>СК


Да. Но если попросить запрос по летчикам, потерям или победам, без дополнительного программирования сделать это не получится.
От SK
К timsz (13.09.2006 16:33:24)
Дата 13.09.2006 16:52:31

Re: Тут не...

>>Можно и нужно. В простейший штатный отчет базы включается возможность выбора записей по фильтрам. Например:
>>- дата или период;
>>- часть (подразделение соединение и т.д.) по умолчанию все;
>>- тип самолета - по умолчанию все.
>>А дальше жмем ОК и получаем отчет(ы), например:
>>летчики
>>потери
>>победы
>>награждения
>>базирование
>>состав м/ч
>>ранения, и т.д.
>>Времени занимает не более минуты. И все сортируется как вы того пожелаете. Далее смотрите в документ в ваших руках и сравниваете (анализируете) информацию, полученную из БД. Вносите коррекцию или дополнение в базу.
>>Все.
>>СК
>

>Да. Но если попросить запрос по летчикам, потерям или победам, без дополнительного программирования сделать это не получится.
Смотрите выше.
Отчет "Летчики"
Ставим дату - получаем всех имеющихся в базе пилотов, которые числятся в строю ВВС на этот день (и отсекаем ненужных по типам самолетов, по фронтам, армиям, дивизиям, частям, эскадрильям).
Ставим фильтр по наградам и получаем список пилотов награжденных на эту дату ОКЗ (к примеру).
Включаем фильтр по потерям и получаем список пилотов, награжденных ОКЗ, которые в этот день погибли.
Включаем фильтр по победам и получаем список награжденных ОКЗ пилотов, добившихся успеха (с комментариями кого, где и какая по счету победа)и погибших в тот же день.
Access так работать не может.
СК
От Seeker
К SK (13.09.2006 16:52:31)
Дата 13.09.2006 21:01:34

Вообще то это реализуемо (-)
От Андрей Диков
К timsz (13.09.2006 12:10:30)
Дата 13.09.2006 13:05:32

Access загнется уже на 10 000 записей (-)
От Samsv
К Андрей Диков (13.09.2006 13:05:32)
Дата 13.09.2006 14:04:30

Так и испугать можно. Елецкий р-н, например, 12468 записей. И не загнулся.

Приветствую! За несколько лет один случай порчи БД был. Да и то давно, в самом начале работы, может сам и виноват.
Возможно, какие-то нюансы случаются при больших объемах вставок и удалений записей без промежуточного сжатия информации, либо при недостатке памяти на компе.
Поэтому стараюсь периодически сжимать базу данных, чтобы избежать этого.
Но это больше для профилактики. А не потому, что грохнулось что-то.


С уважением, Сергей Самодуров, http://samsv.narod.ru
От Андрей Диков
К Samsv (13.09.2006 14:04:30)
Дата 13.09.2006 14:28:29

Re: Так и...

День добрый!

>Но это больше для профилактики. А не потому, что грохнулось что-то.

Я не про "грохнулось что-то". Я про удобство и быстроту пользования. После 10k записей аксесс сильно проседает. Коммерчески его почти никто не юзает, кроме небольших компаний.


С уважением, Андрей
От Seeker
К timsz (13.09.2006 12:10:30)
Дата 13.09.2006 12:19:48

Вперед и с песней.

>До access'а был Paradox.

Мимл человек, в Accesse и писались мои БД, геммор еще тот. Для простеньких БД он сойдет, но для нашей задачи - нет. Хотя, может Вы покруче меня будет в программировании, и для Вас это несложно. Тады умолкаю.

З.Ы. Сколько будет занимать такая БД в Access Вы представляете? И как сложно ее будет модифицировать в курсе?
От timsz
К Seeker (13.09.2006 12:19:48)
Дата 13.09.2006 12:24:04

Да я вообще их не программировал.

Там штатных средств вполне хватает.

Но сейчас, действительно, я иду вперед с песней о XML. Там для удобного вида надо попрограммировать. Но, в общем, это решаемая задача.

Типа: http://www.ilisso.ru/timsz/il2/planes.php
От Seeker
К timsz (13.09.2006 12:24:04)
Дата 13.09.2006 12:49:12

Зря, попробуйте.

>Там штатных средств вполне хватает.

Очень способствует понять что же на самом деле тебе от БД надо.

>Но сейчас, действительно, я иду вперед с песней о XML. Там для удобного вида надо попрограммировать. Но, в общем, это решаемая задача.

Зачем нужна БД? Не только хранить, но и обрабатывать данные. Тут велосипед выдумывать не надо - XML, EXEL, это все ерунда. Для каких-нибудь частных задач и сгодиться, но очень сильно ограничены. Весь мир пользуется специализированными средствами разработки СУБД, где, в той или иной форме, используется механизм SQL. Давайте не будем бежать впереди паровоза, если хотим получить работоспособный результат.
От timsz
К Seeker (13.09.2006 12:49:12)
Дата 13.09.2006 12:56:33

Реляционным базам не хватает гибкости.

Или получается очень сложная структура.

Тогда небольшое изменение в структуру данных может привести к необходимости перелопатить всю базу.

>Давайте не будем бежать впереди паровоза, если хотим получить работоспособный результат.

Рано или поздно паровоз надо поменять на тепло- или электровоз, иначе можно вместе с ним приехать на свалку. ;)
От Seeker
К timsz (13.09.2006 12:56:33)
Дата 13.09.2006 13:03:58

Давайте, оставим кесарю кесарево...

>Или получается очень сложная структура.

>Тогда небольшое изменение в структуру данных может привести к необходимости перелопатить всю базу.

Как я понимаю, мы с Вами не ахти какие специалисты в области информационных технологий. Давайте оставим все эти вопросы профессионалам.
От timsz
К Seeker (13.09.2006 13:03:58)
Дата 13.09.2006 15:29:20

"Тоже мне бином Ньютона" :)

>Как я понимаю, мы с Вами не ахти какие специалисты в области информационных технологий. Давайте оставим все эти вопросы профессионалам.

Ну вообще-то должность у меня IT-специалист :). Хотя, действительлно, на базах данных не специализируюсь.

Но дело в том, что тут не так важна какая-то очень высокая производительность или возможность обработки одновременно сотни запросов к одной записи.

В данной ситуации гораздо важнее мобильность, переносимость и, кроме всего прочего, удобство использования непрофессионалами. В общем и непрофи тоже есть чего пообсуждать.;)
От Seeker
К timsz (13.09.2006 15:29:20)
Дата 13.09.2006 20:59:37

А Баба-Яга против...


>Ну вообще-то должность у меня IT-специалист :). Хотя, действительлно, на базах данных не специализируюсь.

Поздравляю. Значит, Вы сами сможет оценить сильные и слабые стороны сравниваемых решений. Не стесняйтесь экспериментировать.

>Но дело в том, что тут не так важна какая-то очень высокая производительность или возможность обработки одновременно сотни запросов к одной записи.

Производительность не нужна? Ну-ну, посмотрю я на Вас когда несколько десятков тысяч записей будут на ваш запрос обрабатываться. Не у всех стоит Р-4 ЕЕ.

>В данной ситуации гораздо важнее мобильность, переносимость и, кроме всего прочего, удобство использования непрофессионалами. В общем и непрофи тоже есть чего пообсуждать.;)

Формы запросов и отчетов что ли? Или как кнопочки будут располагаться? Давайте оставим все это разработчикам, снабдив их четкими инструкциями.
От timsz
К Seeker (13.09.2006 20:59:37)
Дата 13.09.2006 21:09:11

Re: А Баба-Яга

>Поздравляю. Значит, Вы сами сможет оценить сильные и слабые стороны сравниваемых решений. Не стесняйтесь экспериментировать.

Пока мне кажется, что DOM для таких данных удобнее. Экспериментирую.

>>Но дело в том, что тут не так важна какая-то очень высокая производительность или возможность обработки одновременно сотни запросов к одной записи.
>
>Производительность не нужна? Ну-ну, посмотрю я на Вас когда несколько десятков тысяч записей будут на ваш запрос обрабатываться. Не у всех стоит Р-4 ЕЕ.

Если эта база у меня, то покупка самомого мощного компа окупится по сравнению с зарплатой программиста за 1 месяц. А остальные... Разве не клиент-сервер предлагается. Не, понятно, что чем быстрее, тем лучше. Но в данной задаче это не критично. А кому лень подождать может купить себе мощный комп. Или потерпеть.

>>В данной ситуации гораздо важнее мобильность, переносимость и, кроме всего прочего, удобство использования непрофессионалами. В общем и непрофи тоже есть чего пообсуждать.;)
>
>Формы запросов и отчетов что ли? Или как кнопочки будут располагаться? Давайте оставим все это разработчикам, снабдив их четкими инструкциями.

Нет. Можно понять требования к запросам, отчетам и т.д. и, соответсвенно, понять, как хранить данные.
От Seeker
К timsz (13.09.2006 21:09:11)
Дата 13.09.2006 21:20:58

Это чат какой-то получается...


>Пока мне кажется, что DOM для таких данных удобнее. Экспериментирую.

Отпишитесь о результатах, будет очень интересно, можно на пейджер.


>Разве не клиент-сервер предлагается.

"Ща, уже никто никуда не идет". Идея не нашла заинтересованного отклика в массах, все вернулось к обсуждению локально БД заточенной для решения конкретной задачи.


>Нет. Можно понять требования к запросам, отчетам и т.д. и, соответсвенно, понять, как хранить данные.

В яблочко. Только для этого нужно решить, что же нужно от БД. Пока речь идет об описании железок.
От timsz
К timsz (13.09.2006 12:24:04)
Дата 13.09.2006 12:24:43

ЗЫ Хотя наполнить базу можно и без программирования.

Даже поудобнее будет.
От Fishbed
К Seeker (12.09.2006 21:45:24)
Дата 13.09.2006 09:26:39

Re: Давайте закругляться.

>Обсуждать детали можно еще долго, однако хочу подвести итоги (для себя) и поставить вопросы....

Профессиональный анализ! Честный и откровенный, но не очень оптимистический, однако... That's life!

С уважением,
От Seeker
К Fishbed (13.09.2006 09:26:39)
Дата 13.09.2006 11:56:26

Да нет...


>Профессиональный анализ! Честный и откровенный, но не очень оптимистический, однако... That's life!

"это не жизнь такая - это мы такие", переиначу культовую фразу из сами-знаете-откуда.

Что имеем? Есть группка энтузиастов/любителей истории советской авиации, деятельность которой выражается в обсуждении интересных им вопросов плюс время от времени реализация (разной степени успешности) индивидуальных (в основном) проектов - выпуск книг/поддржка сайта и т.п. Но организации как таковой нет, вот что печально. А могли бы создать "военно-патриотическое общество", ("Спартак", например :)) ) выбрать орг. комитет, который занимался бы реализацией тех или иных проектов, организацией встреч, поддерживал бы деятельность исследователей, помогал в публикации их трудов и т.д. и т.п. Остальные - платили бы членские взносы ("основная обязанность комсомольца - своевременно выплачивать членские взносы"), при желание жертвовали какие-то суммы в кассу (или поддержку определенного проекта), занимались общественной работой (привлечение спонсоров, работа с молодежью, вербовка новых членов; э-э, что-то меня занесло, хотя идея верная и правильная), имея за собой поддержку общества информ. материалами и красивые корочки. Помогает, знаете ли, в общении и сильно экономит время при знакомстве. Свежий пример - звоню на договориться о посещении школьного музея. Первый вопрос - "а вы кто такие?", мы молодые идиоты, трам-там, желаем осмотреть ваш музей, принести подарки и т.п. "А зачем?", - и думаешь, а действительно зачем, как объяснить на пальцах зачем нам это надо. А вот "военно-патриотическое общество" или "Общество друзей воздушного флота" таких вопросов вызывать не будет, да и у нас, как у представителей такого общества авторитет в глазах обывателя будет выше. Ну и т.д и т.п.

Ну что, будем организовываться?
От Fishbed
К Seeker (13.09.2006 11:56:26)
Дата 13.09.2006 13:56:01

Re: Да нет...

>Что имеем? Есть группка энтузиастов/любителей истории советской авиации, деятельность которой выражается в обсуждении интересных им вопросов плюс время от времени реализация (разной степени успешности) индивидуальных (в основном) проектов - выпуск книг/поддржка сайта и т.п.

Группа - неформальная: хочу хожу на сайт, хочу нет, что интересно, то и обсуждаю, что не интересно - не обсуждаю. В этом то сила и привлекательность этой группки. Никакой обязаловки. К тому же нельзя забывать, что народ здесь фактически со всего бывшего Союза + североамериканские самые соединненые штаты.

>Но организации как таковой нет, вот что печально.

Печально, конечно! Но что делать, жизнь такая.

>А могли бы создать "военно-патриотическое общество", выбрать орг. комитет, который занимался бы реализацией тех или иных проектов, организацией встреч, поддерживал бы деятельность исследователей, помогал в публикации их трудов и т.д. и т.п. Остальные - платили бы членские взносы, при желание жертвовали какие-то суммы в кассу...

В нынешних "коммерческих" условиях сила любой организации в сумме денег, которой эта организация распоряжается... Откуда деньги возьмутся? Членские взносы? Для приличного бюджета это должны быть большие деньги. Давайте посчитаем: на нашем форуме регулярно бывает от силы 100-150 человек. Книжонку тиражом в 1000 экз., даже очень слабого качества, издать стоит плюс-минус 500 у.е. 500 делим на 100 - это уже 5 у.е., т.е. грубо 150 рубликов. А если проектов будет несколько? 5-10? 1500 руб. отдать в качестве взносов многие из присутствующих здесь будут готовы? А офис с длинноногими секретаршами где будет? В Москве, в Киеве, в Сарове или Питере?

> ... красивые корочки

Готов в качестве дара за свой счет напечатать пару десятков. И что дальше? - А это что за организация, не знаю такую?! И вообще корочки вон на Арбате за 50 руб. продаются...

> "А зачем?", - и думаешь, а действительно зачем, как объяснить на пальцах зачем нам это надо.

Именно так! Вот именно в этом корень проблемы!!! Хоть корочку показывай, хоть деньги предлагай: да не нужны мне ваши деньги...

> А вот "военно-патриотическое общество"

А в ответ скажут, а-а-а, "черные копатели"! Или расскажут массу примеров, когда уже приходили, брали, обещали вернуть, но не вернули.

>Ну что, будем организовываться?

См. выше....

С уважением,
От Seeker
К Fishbed (13.09.2006 13:56:01)
Дата 13.09.2006 15:37:37

Game over...


>Группа - неформальная: хочу хожу на сайт, хочу нет, что интересно, то и обсуждаю, что не интересно - не обсуждаю. В этом то сила и привлекательность этой группки. Никакой обязаловки.

Так ведь и в организацию никто не тянет. Хочешь вступай, и участвуй/посильно помогай в работе, хочешь - продолжай ходить на сайт/форум, никто ж мешает. "Не можешь любить - сиди дружи" :))

>К тому же нельзя забывать, что народ здесь фактически со всего бывшего Союза + североамериканские самые соединненые штаты.

И что с того? Не вижу проблем.


>Печально, конечно! Но что делать, жизнь такая.

Менять будем?


>В нынешних "коммерческих" условиях сила любой организации в сумме денег, которой эта организация распоряжается... Откуда деньги возьмутся? Членские взносы? Для приличного бюджета это должны быть большие деньги. Давайте посчитаем:

Это детали. Нет смысла их обсуждать, когда нет заинтересованности в объединении.


>> "А зачем?", - и думаешь, а действительно зачем, как объяснить на пальцах зачем нам это надо.
>
>Именно так! Вот именно в этом корень проблемы!!! Хоть корочку показывай, хоть деньги предлагай:


Правильно, поэтому говорим - вот наш сайт, наши работы, наши телефоны - работает, кстати. А можно пристроится под "крылышко" какой-нибудь серьезной организации, как предлагает deruluft.


>А в ответ скажут, а-а-а, "черные копатели"!

Уже, уже называют, причем свои же дразнят, собаки. Говорю, еще раз назовете, как двину вот этим металлодетектором :)).


>Или расскажут массу примеров, когда уже приходили, брали, обещали вернуть, но не вернули.

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

>>Ну что, будем организовываться?
>
>См. выше....

Ясно - "было бы не плохо, если кто-нибудь этим занялся". Ожидаемо.

Поэтому, вопрос уважаемого СК по созданию БД так и сгинет, увы. Не будет ни выработки ТТЗ, ни, тем паче, реализации.

"Плакать хочется" (с)
От Fishbed
К Seeker (13.09.2006 15:37:37)
Дата 13.09.2006 17:38:35

Re: Game over...

>>В нынешних "коммерческих" условиях сила любой организации в сумме денег, которой эта организация распоряжается... Откуда деньги возьмутся? Членские взносы? Для приличного бюджета это должны быть большие деньги. Давайте посчитаем:
>
>Это детали. Нет смысла их обсуждать, когда нет заинтересованности в объединении.

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

А заинтересованность есть. Когда и где проводим организационное собрание по созданию "Общества сумашедших и бескорыстных любителей истории отечественной авиации (ОСБЛИА)"? Кто устав писать будет?

> А можно пристроится под "крылышко" какой-нибудь серьезной организации, как предлагает deruluft.

Какой? МО РФ - уже обсуждали. С объединенными ВВС и ПВО, ИМХО, ситуация не лучше? РОСТО - не смешите мои тапочки... Серьезной организации НЕ серьезные любительные организации нужны не более, чем реактивному двигателю винт.

>"Плакать хочется" (с)

Слезами делу не поможешь... Да и не верит Москва (и Подольск с ЦАМО) слезам.

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

С уважением,
От Seeker
К Fishbed (13.09.2006 17:38:35)
Дата 13.09.2006 21:07:48

Ну, так...


>А заинтересованность есть. Когда и где проводим организационное собрание по созданию "Общества сумашедших и бескорыстных любителей истории отечественной авиации (ОСБЛИА)"? Кто устав писать будет?

По сообщениям, ничего такого не наблюдается. А организоваться хоть во что-то уже пытались, даже и наработки есть :))

>> А можно пристроится под "крылышко" какой-нибудь серьезной организации, как предлагает deruluft.
>
>Какой? МО РФ - уже обсуждали. С объединенными ВВС и ПВО, ИМХО, ситуация не лучше? РОСТО - не смешите мои тапочки... Серьезной организации НЕ серьезные любительные организации нужны не более, чем реактивному двигателю винт.

А вот, представьте, говорят - "есть варианты".

>А там глядишь и критическая масса сформируется...

Да не образуется, а наоборот - рассосется. Быт, работа, семья и т.п. вообще ни на что времени не оставят. "Танцуй пока молодой, мальчик" :)) Или наоборот, вышел на пенсию...
От Fishbed
К Seeker (13.09.2006 21:07:48)
Дата 14.09.2006 09:15:02

Re: Ну, так...

>По сообщениям, ничего такого не наблюдается. А организоваться хоть во что-то уже пытались, даже и наработки есть :))

Таки, если наработки есть: когда и где организуемся?

>А вот, представьте, говорят - "есть варианты".

Пока трудно "представить", не зная, что "говорят".

>Да не образуется, а наоборот - рассосется.

Есть ли смысл разводить дискуссию по поводу стакана воды на половину пустого или полного?

С уважением,
От SK
К Seeker (13.09.2006 15:37:37)
Дата 13.09.2006 16:27:35

Re: Game over...

>И правильно, что пошлют. В таких случаях говорят, прихожу со своим оборудованием, на ваших глазах копирую, пою от пуза/плачу за копирование и т.п. Идеальный вариант - свой ноут со сканером. Ясен перец, что не у каждого такая штука есть, ну так, общество (гипотетическое) поможет - скомплектует один/два "тревожных чемодачника", берут уважаемые люди для работы на время.
Я, например ,благодаря хорошим людям пользуюсь таким чемоданчиком. Так что это реально. Единственная мелочь - пользуешься тем что есть и иногда возникают сложности с перебросом данных. Второе - теряется драгоценное архивное (иногда) время на получение и сдачу чемоданчика.
>Поэтому, вопрос уважаемого СК по созданию БД так и сгинет, увы. Не будет ни выработки ТТЗ, ни, тем паче, реализации.
Уважаемый СК плакать не будет, а будет создавать базу самостоятельно. Мне без нее никак. А вопрос был задан коллегам, чтобы им эта база пригодилась при случае и была удобна для работы. Все объять невозможно, а вот определение какие документы в архиве можно оставить без внимания, а какие нужно просмотреть обязательно, значительно экономит время.
СК
От Seeker
К SK (13.09.2006 16:27:35)
Дата 13.09.2006 21:10:37

Ну, тогда это просто...


>Уважаемый СК плакать не будет, а будет создавать базу самостоятельно.

мои "сны о чем-то большем", выходящие за рамки Вашей частной задачи. Смиренно умолкаю...
От deruluft
К Seeker (13.09.2006 11:56:26)
Дата 13.09.2006 12:04:52

Re: Да нет...

>Ну что, будем организовываться?

Да, давай :)
От Seeker
К deruluft (13.09.2006 12:04:52)
Дата 13.09.2006 12:54:57

Угу, соорганизуемся на пиво попить. Третий нужен!!

>>Ну что, будем организовываться?
>
>Да, давай :)

"Могучая кучка", млин.
От SK
К SK (11.09.2006 11:55:23)
Дата 12.09.2006 16:20:28

Re: База данных

Коллеги, возможность и невозможность создания базы мы уже обсосали.
А как насчет сути вопроса. Ставлю его ребром:
КТО персонально и ЧТО хочет видеть в базе по самолетам (для начала) и В КАКОМ РАЗРЕЗЕ (какой вывод информации эта база должна обеспечить для цели ваших исследований)?
Спасибо!
СК
От timsz
К SK (12.09.2006 16:20:28)
Дата 12.09.2006 17:18:40

Мысли

Интерес могут представлять три базы: по обозначениям, по конструкциям и по конкретным самолетам. Если объединить в одну, будет каша, так как полно случаев, когда одно обозначение давалось разным конструкциям, один самолет мог иметь несколько обозначений и в разное время разную конструкцию, одна конструкция имела несколько обозначений и т.д.

Соответственно, если делать базу по самолетам, по каждому надо иметь:
- список обозначений
- список конструкций
- серийный номер(а)
- бортовой номер(а)
- дату выпуска
- производитель(и)
- первый полет
- эксплутант
- интересные факты
- дату списания
- сегодняшнее состояние
От SK
К timsz (12.09.2006 17:18:40)
Дата 13.09.2006 15:45:31

Вот собственно как это выглядит у меня в Accesse (пока)


СК
От timsz
К SK (13.09.2006 15:45:31)
Дата 13.09.2006 16:26:36

Re: Вот собственно...

Я правильно понял, что есть таблица самолетов, к ней привязаны таблица моторов, движения и таблица утрат (не поянтно, почему тут таблица, утрат может быть несколько?)?

Но этого мало, так как нужна как минимум таблиица бортовых номеров. Оборудование тоже могло меняться на одном и том же самолете, и если собирать в базу все самолеты, то список оборудование будет просто огромным.

И это хорошо, если о самолете нет противоречивой информации. А что если по разным данным получаются разные даты выпуска? ;)
От SK
К timsz (13.09.2006 16:26:36)
Дата 13.09.2006 16:34:40

Re: Вот собственно...

>Я правильно понял, что есть таблица самолетов, к ней привязаны таблица моторов, движения и таблица утрат (не поянтно, почему тут таблица, утрат может быть несколько?)?
Причин и дат потерь может быть несколько в разных документах. Плюс туда можно заносить какие-либо другие данные по машине с привязкой к дате или источнику
>Но этого мало, так как нужна как минимум таблиица бортовых номеров. Оборудование тоже могло меняться на одном и том же самолете, и если собирать в базу все самолеты, то список оборудование будет просто огромным.
Зачем нам список номеров ШКАСов на самолете или номеров часов? Если бы самолеты находили в болотах сотнями... А так это просто потеря времени в архиве на поиск бесполезной информации.
>И это хорошо, если о самолете нет противоречивой информации. А что если по разным данным получаются разные даты выпуска? ;)
Там уже по степени доверия к источнику. Первичны данные завода и военпреда. В полковых документах эти цифры не всегда точны.
СК
От Seeker
К SK (13.09.2006 16:34:40)
Дата 13.09.2006 21:14:40

Опять же...


>>Но этого мало, так как нужна как минимум таблиица бортовых номеров. Оборудование тоже могло меняться на одном и том же самолете, и если собирать в базу все самолеты, то список оборудование будет просто огромным.
>Зачем нам список номеров ШКАСов на самолете или номеров часов? Если бы самолеты находили в болотах сотнями... А так это просто потеря времени в архиве на поиск бесполезной информации.

Раскиньте БД на несколько. Ведите отдельно по моторам, рациям, ШКАСАМ и т.п. с их серийными номерами и увязывайте это с БД по самолетам. Рекомендую почитать литературу по проектированию СУБД, про нормализацию там пишут.
От timsz
К Seeker (13.09.2006 21:14:40)
Дата 13.09.2006 21:57:55

По опыту очень много таблиц получается - громоздко и тяжко.

Сложно редактировать. Правда, когда мало, приходится много избыточной информации хранить - сложно исправлять ошибки. :)
От летнаб
К SK (13.09.2006 16:34:40)
Дата 13.09.2006 16:50:12

Re: Вот собственно...

Во-первых, то, что Вами представлено выше - это уже СУПЕР.
Снимаю шляпу и замираю. А вот-во вторых
>Зачем нам список номеров ШКАСов на самолете или номеров часов? Если бы самолеты находили в болотах сотнями... А так это просто потеря времени в архиве на поиск бесполезной информации.
Действительно, к сожалению, сотнями их не находят, но все же (мечты) для потерянных в боях самолетов это было бы бесценно (наверное, в первую очередь для поисковиков).
Но, осознавая ОБЪЕМ информации и необходимое время на ее поиск (я о номерах вооружения) - задача, скорее всего неподъемная. Во всяком случае, для одного человека.
От SK
К летнаб (13.09.2006 16:50:12)
Дата 13.09.2006 17:05:46

Re: Вот собственно...

>Действительно, к сожалению, сотнями их не находят, но все же (мечты) для потерянных в боях самолетов это было бы бесценно (наверное, в первую очередь для поисковиков).
Публикации на сайте раздела со сылками на архив и на конкретные номера дел, в которых эта информация есть, вполне достаточно. Далее запрос по адресу архива с выходными данными дела и получение (иногда за небольшую плату - за перелистывание страниц) необходимой информации.
СК
От летнаб
К SK (13.09.2006 17:05:46)
Дата 13.09.2006 17:20:55

Согласен. Все правильно. (-)
От timsz
К SK (13.09.2006 16:34:40)
Дата 13.09.2006 16:49:53

Re: Вот собственно...

>Зачем нам список номеров ШКАСов на самолете или номеров часов? Если бы самолеты находили в болотах сотнями... А так это просто потеря времени в архиве на поиск бесполезной информации.

Нет, я о том, что на самолете могла стоять один тип станции, а потом другой. Могла поменяться конструкция. Более того, даже обозначение самолета могло поменяться (не говоря о том, что их могло быть несколько). :) Наверное, если делать базу, заточенную под поиск, это не так важно. Но для универсальной базы это может быть важно.

>>И это хорошо, если о самолете нет противоречивой информации. А что если по разным данным получаются разные даты выпуска? ;)
>Там уже по степени доверия к источнику. Первичны данные завода и военпреда. В полковых документах эти цифры не всегда точны.

Но правильнее, думаю, держать и ту, и другую информацию. Тем более, что вполне вероятно, что может быть информация одинаковая по надежности.
От SK
К timsz (13.09.2006 16:49:53)
Дата 13.09.2006 17:01:42

Re: Вот собственно...

>>Зачем нам список номеров ШКАСов на самолете или номеров часов? Если бы самолеты находили в болотах сотнями... А так это просто потеря времени в архиве на поиск бесполезной информации.
>
>Нет, я о том, что на самолете могла стоять один тип станции, а потом другой. Могла поменяться конструкция. Более того, даже обозначение самолета могло поменяться (не говоря о том, что их могло быть несколько). :) Наверное, если делать базу, заточенную под поиск, это не так важно. Но для универсальной базы это может быть важно.
Из всех просмотренных мною архивных документов я еще ни разу не встречал записей о замене на борту таком-то такого-то оборудования с таким-то номером на номер такой-то (или тип). Это все должно быть в фомулярах на самолеты, но их в архивах увы нет (и скорее всего они и не сдавались как маловажные). А для радиостанции например знать была она приемной или приемопередающей важнее, чем ее тип.
>>>И это хорошо, если о самолете нет противоречивой информации. А что если по разным данным получаются разные даты выпуска? ;)
>>Там уже по степени доверия к источнику. Первичны данные завода и военпреда. В полковых документах эти цифры не всегда точны.
>
>Но правильнее, думаю, держать и ту, и другую информацию. Тем более, что вполне вероятно, что может быть информация одинаковая по надежности.
Для этого и есть табличка внизу.
СК
От timsz
К SK (13.09.2006 17:01:42)
Дата 13.09.2006 17:36:29

Тут действительно вопрос в том, зачем нужна база.

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

Меня больше интересуют, например, самолеты вроде Як-1 №35-60. :)
От deruluft
К SK (11.09.2006 11:55:23)
Дата 12.09.2006 11:58:03

пара мыслей

1. В каком формате (excel, dbf, access, oracle, ...) делать базу совершенно неважно.
2. База не должна быть реляционной, то есть она не должна состоять из связанных ссылками таблиц. Она должна состоять из независимых друг от друга таблиц, которые могут быть связаны по единым идентификаторам. Нужно все это для того, чтобы база могла быть легко дополнена новыми данными, или наоборот разбита на части.
3. База должна проектироваться с учетом ее возможного on-line существования.
4. База должна быть многопользовательской, это значит, что инфромация может дополняться большим числом пользователей, и как следствие может быть неверной (случайно или намеренно). Это значит, что база должна хранить историю изменений с возможностью отката либо сортировки по источнику информации.
От SK
К deruluft (12.09.2006 11:58:03)
Дата 12.09.2006 15:46:45

Re: пара мыслей

>2. База не должна быть реляционной, то есть она не должна состоять из связанных ссылками таблиц. Она должна состоять из независимых друг от друга таблиц, которые могут быть связаны по единым идентификаторам. Нужно все это для того, чтобы база могла быть легко дополнена новыми данными, или наоборот разбита на части.
Единственными связующими звеньями, позволяющими много вариантность нашей базы могут быть:
а) воинская часть, подразделение;
б) тип самолета.
Остальные кусочки базы заполняются в связи с этими ключами (справочниками) различными формализированными документами (акт потери или списания), карточка самолета (мотора), оперсводка, донесение о ремонте и т.д.
СК
От Seeker
К deruluft (12.09.2006 11:58:03)
Дата 12.09.2006 13:18:57

Не согласен...

>1. В каком формате (excel, dbf, access, oracle, ...) делать базу совершенно неважно.

Важно, в противном случае, будет трудно (или потребует каких-то усилий) перенести ее на другую платформу. Неважно с чем это будет связано - объединение проектов, смена СУБД и т.п.

>2. База не должна быть реляционной, то есть она не должна состоять из связанных ссылками таблиц. Она должна состоять из независимых друг от друга таблиц, которые могут быть связаны по единым идентификаторам. Нужно все это для того, чтобы база могла быть легко дополнена новыми данными, или наоборот разбита на части.

Нет, БАЗЫ должны быть реаляционными, связанные друг с другом. Другое дело КАК и КАКИЕ назначить ключи. Кстати, то что ты пишешь, как раз и есть предлагаемое мной разбиение одной базы на несколько (таблицы, как ты их именуешь). Что получим - есть несколько БД, связанных между собой. Возникла необходимость в одной из них ввести новые поля - пожалуйста, вводи, главное, чтобы связи не затрагивало. Короче, чего я распинаюсь - нормализация БД это называется.

>3. База должна проектироваться с учетом ее возможного on-line существования.

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

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

Ну, backup во многих СУБД есть, плюс можно ввести некоторое администьрирование, то бишь приоритет одних участников над другими, и т.д. и т.п. А есть еще такой вариант - существуют ДВЕ БД, одна тестовая, другая - рабочая. То есть, идет первоначальное заполнение тестовой БД, затем, по определенным критериям информация переносится в основную.

Естественно, надо понимать, что желающих поместить результаты своих исследований на всеобщее (опять же, можно ограничить доступ к ряду записей) обозрение найдется крайне мало, если вообще таковые будут. Но дело не в этом, задача стоит выработать единые требования (и возможно, частично реализация) к БД. А работать можно будет, как с локальной БД со своими наработками, так и с общей.

Хотелось бы чтобы этим занялись профессиональные разработчики, пусть и за деньги, чем страдать от любительских "косяков".
От SK
К Seeker (12.09.2006 13:18:57)
Дата 12.09.2006 15:56:19

Re: Не согласен...

>>4. База должна быть многопользовательской, это значит, что инфромация может дополняться большим числом пользователей, и как следствие может быть неверной (случайно или намеренно). Это значит, что база должна хранить историю изменений с возможностью отката либо сортировки по источнику информации.
>Естественно, надо понимать, что желающих поместить результаты своих исследований на всеобщее (опять же, можно ограничить доступ к ряду записей) обозрение найдется крайне мало, если вообще таковые будут. Но дело не в этом, задача стоит выработать единые требования (и возможно, частично реализация) к БД. А работать можно будет, как с локальной БД со своими наработками, так и с общей.
>Хотелось бы чтобы этим занялись профессиональные разработчики, пусть и за деньги, чем страдать от любительских "косяков".
Если это будет заказной программный продукт, то есть вполне реальная возможность его последующей реализации с какой-то степенью защиты (эл.ключ на комп) и, соответственно, подписки на обновления базы, распространяемой через сеть. Это подпитка для тех, кто будет базу строить.
Владельцам права на использовние локальной копии, при их желании дополнить базу своими наработками, можно будет делать скидки.
Еще договоры с конечными владельцами оригинальных фото (негативов), схем окраски, чертежей на их тиражирование, раз уж этот раздел будет присутствовать в базе.
СК
От deruluft
К SK (12.09.2006 15:56:19)
Дата 12.09.2006 16:11:35

Re: Не согласен...

>>Естественно, надо понимать, что желающих поместить результаты своих исследований на всеобщее (опять же, можно ограничить доступ к ряду записей) обозрение найдется крайне мало, если вообще таковые будут. Но дело не в этом, задача стоит выработать единые требования (и возможно, частично реализация) к БД. А работать можно будет, как с локальной БД со своими наработками, так и с общей.
Нет, "экономическая модель", может быть другая:
- все база никому не передается (не существует локальных копий);
- экспорт всех данных пользователем невозможен;
- пользователь оплачивает подписку
- контроль за авторами, использующими базу (мы же попутно и журналы/газеты/книги читаем и заносим :). Ссылка на базу обязательна :). Использовал, но не платил - отключаем нафиг.

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

>Владельцам права на использовние локальной копии, при их желании дополнить базу своими наработками, можно будет делать скидки.
Никаких локальных копий :). Но активным пользователям, и владельцам информации - скидка.
От SK
К deruluft (12.09.2006 16:11:35)
Дата 12.09.2006 16:47:33

Re: Не согласен...

>>>Естественно, надо понимать, что желающих поместить результаты своих исследований на всеобщее (опять же, можно ограничить доступ к ряду записей) обозрение найдется крайне мало, если вообще таковые будут. Но дело не в этом, задача стоит выработать единые требования (и возможно, частично реализация) к БД. А работать можно будет, как с локальной БД со своими наработками, так и с общей.
>Нет, "экономическая модель", может быть другая:
>- все база никому не передается (не существует локальных копий);
>- экспорт всех данных пользователем невозможен;
>- пользователь оплачивает подписку
>- контроль за авторами, использующими базу (мы же попутно и журналы/газеты/книги читаем и заносим :). Ссылка на базу обязательна :). Использовал, но не платил - отключаем нафиг.
Имейте в виду, что эта база данных весьма специфический продукт и число ее активных пользователей будет небольшим (меньше, чем у авиационных журналов на порядок, а то и на два). То есть ломать и выкладывать как остальные базы на прилавок - на такой уж выгодный бизнес.
Мне, допустим, неприятна (на данном этапе развития IT) сама идея, что придется за каким-то мелким вопросом постоянно лазить в сеть.
А в распространяемую локальную копию входят тело программы, управляющей базой данных, с защитой от несанкционированного использования и чистая база:
а) которую я могу сам наполнить тем, что мне нужно;
б) в которую я могу интегрировать как часть общей купленную мной у М.Быкова (и т.д.) базу;
в) которую я могу сам перестроить по нуждам своего исследования;
г) в которой я мог бы вносить изменения и дополнения к уже купленным частям баз данных, и чтобы при покупке обновлений мои измененные, доработанные или добавленные данные не затирались обновлением.
д) из которой я могу выгрузить копию какого-то блока данных с внесенными мной изменениями и поделиться, например, с Hippo. Или выгрузить свои изменения и предложить их на продажу всем желающим.
Т.е. программа отдельно, база отдельно.
СК
От Seeker
К SK (12.09.2006 16:47:33)
Дата 12.09.2006 22:04:04

А вы друг другу и не противоречите...

>>Нет, "экономическая модель", может быть другая:
>>- все база никому не передается (не существует локальных копий);

Да, не передается, но существует возможность клиенту работать с собственной локальной БД.

>>- экспорт всех данных пользователем невозможен;

Ну, что-то он сможет получить. Запариться, правда :))

>>- пользователь оплачивает подписку
>>- контроль за авторами, использующими базу (мы же попутно и журналы/газеты/книги читаем и заносим :). Ссылка на базу обязательна :). Использовал, но не платил - отключаем нафиг.

Да, и по суду - иск. Для всего описанного требуется регистрация какого-нибудь ю/л "Рога и Копыта".

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

А это не наши проблемы. Разработчики просто желают защитить свои вложения в продукт. Если ломать не выгодно, покупайте подписку.

>Мне, допустим, неприятна (на данном этапе развития IT) сама идея, что придется за каким-то мелким вопросом постоянно лазить в сеть.

А что делать? Связь сейчас, слава Богу, не проблема.

>А в распространяемую локальную копию входят тело программы, управляющей базой данных, с защитой от несанкционированного использования и чистая база:
>а) которую я могу сам наполнить тем, что мне нужно;
>б) в которую я могу интегрировать как часть общей купленную мной у М.Быкова (и т.д.) базу;

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

>в) которую я могу сам перестроить по нуждам своего исследования;

А вот это фигушки, внимательно читайте лицензионное соглашение :)), где прямо говориться о том, что клиент обязуется не изменять исходный код (модифицировать) продукта. Если желаете действовать в рамках Open Source, вперед - займитесь собственной разработкой вместе с желающими. Мы же говорим о том, что продукт будет стороннего разработчика, который отвечает за корректную и стабильную работу. Желаете что-то дополнительно, пожалуйста - за отдельные деньги. И не вижу в этом ничего страшного.

>г) в которой я мог бы вносить изменения и дополнения к уже купленным частям баз данных, и чтобы при покупке обновлений мои измененные, доработанные или добавленные данные не затирались обновлением.

Только обратная связь с разработчиками позволит Вам это сделать без проблем. В противном случае - читайте лицензионное соглашение :))

>д) из которой я могу выгрузить копию какого-то блока данных с внесенными мной изменениями и поделиться, например, с Hippo. Или выгрузить свои изменения и предложить их на продажу всем желающим.

В таком случае, контора снимает с себя ответственность за возможные последствия использования БД от стороннего разработчика. Т.е., вы это делаете "на свой страх и риск". Проще заранее согласовать структуру Ваше БД с разработчиками.

>Т.е. программа отдельно, база отдельно.

Да на здоровье.


Фу-у..
От SK
К Seeker (12.09.2006 22:04:04)
Дата 13.09.2006 10:56:01

Re: А вы

>>в) которую я могу сам перестроить по нуждам своего исследования;
>
>А вот это фигушки, внимательно читайте лицензионное соглашение :)), где прямо говориться о том, что клиент обязуется не изменять исходный код (модифицировать) продукта. Если желаете действовать в рамках Open Source, вперед - займитесь собственной разработкой вместе с желающими. Мы же говорим о том, что продукт будет стороннего разработчика, который отвечает за корректную и стабильную работу. Желаете что-то дополнительно, пожалуйста - за отдельные деньги. И не вижу в этом ничего страшного.
А добавить (сконструировать) свои документы, отчеты, разделы БД на основе имеющегося движка (и не задевая разработанные модули) - почему бы нет?
СК
От Seeker
К SK (13.09.2006 10:56:01)
Дата 13.09.2006 11:25:13

А потому.


>А добавить (сконструировать) свои документы, отчеты, разделы БД на основе имеющегося движка (и не задевая разработанные модули) - почему бы нет?

Ну, нет - так нет :)). Все зависит от того, на чем такая СУБД реализована (на мой взгляд лучше всего подойдет SQL-сервер), чтобы учтя все тонкости реализации можно было что-то свое подключать. В конце концов, ведь не движок разрабатывается, а СУБД.
От SK
К Seeker (13.09.2006 11:25:13)
Дата 13.09.2006 15:57:35

Re: А потому.

>Ну, нет - так нет :)). Все зависит от того, на чем такая СУБД реализована (на мой взгляд лучше всего подойдет SQL-сервер), чтобы учтя все тонкости реализации можно было что-то свое подключать. В конце концов, ведь не движок разрабатывается, а СУБД.
Вот теперь возникает резонный вопрос: А зачем все это?
Мне база по самолетам нужна как рабочий инструмент, чтобы после постепенного введения туда обрывочных порой записей архивных тетрадок получитькакие-то сводные данные и определить для каждой части:
1. Сколько машин было в конкретной части на интересующую меня дату (исправных, неисправных, в реморганах).
2. Поступление и потери (в т.ч.причины потерь) самолетов за определенный период.
3. По возможности иметь справочные данные: бортовой номер каждой машины, закрепление за пилотом, номера мотора и т.д.
Есть еще идеи?
Теперь вопрос к вам: зачем нужна база по пилотам (кроме как для справки)?
СК
От Seeker
К SK (13.09.2006 15:57:35)
Дата 13.09.2006 20:52:08

Прошу пардону...


за искажение генеральной линии партии.

>Мне база по самолетам нужна как рабочий инструмент, чтобы после постепенного введения туда обрывочных порой записей архивных тетрадок получить какие-то сводные данные и определить для каждой части:

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

>Теперь вопрос к вам: зачем нужна база по пилотам (кроме как для справки)?

Прохождение службы, боевая работа (в идеале, с деталировкой событий), фото на данную персоналию, и источники на основании чего все это составлено. Железяки не так уж важно, это к стендовикам.
От Alex
К SK (13.09.2006 15:57:35)
Дата 13.09.2006 17:54:54

Re: А потому.

>1. Сколько машин было в конкретной части на интересующую меня дату (исправных, неисправных, в реморганах).
>2. Поступление и потери (в т.ч.причины потерь) самолетов за определенный период.
>3. По возможности иметь справочные данные: бортовой номер каждой машины, закрепление за пилотом, номера мотора и т.д.
>Есть еще идеи?

>Теперь вопрос к вам: зачем нужна база по пилотам (кроме как для справки)?

У каждого своя религия:) Для меня лично матчасть вторична, а первичны люди. И если я (грешен) тоже что-то кропаю, то для того, чтобы знать:

1. Сколько пилотов было в конкретной части на интересующую меня дату (исправных, неисправных, в реморганах).
2. Поступление и потери (в т.ч.причины потерь) пилотов за определенный период.
3. По возможности иметь справочные данные: бортовой номер каждого пилота, закрепление за машиной, и т.д. :)
От SK
К Alex (13.09.2006 17:54:54)
Дата 14.09.2006 11:18:35

Это две стороны одной медали

Вам, чтобы описать боевые действия на каком-то участке фронта не обойтись без численности, а мне соответственно не обойтись без ответа на вопрос, а были ли пилоты, чтобы поднять всю армаду в воздух, их подготовка и т.д.
Плюс из-за недостатка документов (или нужной информации в документах), вы знаете, часто приходится сравнивать между собой два этих массива данных, чтобы определить, например, по точной дате гибели летчика дату потери самолета по записи типа: "с 22.6 по 22.7.43 потери ? иап 1 Як-7" и соответственно наоборот.
Именно в этом смысле я вижу необходимость взаимодействия баз. Плюс разделение труда - тоже очень выгодная вещь (у большинства есть семьи, дети, а также гаражи, сараи, ремонт жилища и зарабатывание хлеба насущного).
СК
От deruluft
К Seeker (12.09.2006 13:18:57)
Дата 12.09.2006 13:37:59

Re: Не согласен...

>Важно, в противном случае, будет трудно (или потребует каких-то усилий) перенести ее на другую платформу. Неважно с чем это будет связано - объединение проектов, смена СУБД и т.п.
Да не важно :). Перенести с однй платформы на другую это не является пробемой. Экспорт - импорт, попутно выверка :).

>Нет, БАЗЫ должны быть реаляционными, связанные друг с другом. Другое дело КАК и КАКИЕ назначить ключи. Кстати, то что ты пишешь, как раз и есть предлагаемое мной разбиение одной базы на несколько (таблицы, как ты их именуешь). Что получим - есть несколько БД, связанных между собой. Возникла необходимость в одной из них ввести новые поля - пожалуйста, вводи, главное, чтобы связи не затрагивало. Короче, чего я распинаюсь - нормализация БД это называется.
Да, ключи это залог успеха. Остальное при встрече обсудим.

>Ну, backup во многих СУБД есть, плюс можно ввести некоторое администьрирование, то бишь приоритет одних участников над другими, и т.д. и т.п. А есть еще такой вариант - существуют ДВЕ БД, одна тестовая, другая - рабочая. То есть, идет первоначальное заполнение тестовой БД, затем, по определенным критериям информация переносится в основную.
Нет, этих механизмов недостаточно. Обязательное хранение истории изменений.

>Хотелось бы чтобы этим занялись профессиональные разработчики, пусть и за деньги, чем страдать от любительских "косяков".
Да, все правильно.

В любом случае технических проблем нет. Есть вопросы "Зачем?" и "что в результате?"
в музей пойдем когда - обсудим.
От hunter019
К deruluft (12.09.2006 13:37:59)
Дата 12.09.2006 15:39:47

А в какой музей идете? (-)
От Seeker
К deruluft (12.09.2006 13:37:59)
Дата 12.09.2006 13:52:11

А теперь - согласен...

>Да не важно :). Перенести с однй платформы на другую это не является пробемой. Экспорт - импорт, попутно выверка :).

Не проблема, но гемморой и лишняя работа. Зачем?

>В любом случае технических проблем нет. Есть вопросы "Зачем?" и "что в результате?"

Есть проблема в организации. Самым правильным и наглядно полезным явилось бы создание БД по книжкам/журналам, возможно, документам для тех кому надо. Т.е., реализация очередного заброшенного мной проекта электронной библиотеки :))))

>в музей пойдем когда - обсудим.

Яволь, обергрупеннфюрер. Пошел звонить. Разрешите идти! :))
От SK
К Seeker (12.09.2006 13:52:11)
Дата 12.09.2006 15:59:08

Re: А теперь

>Есть проблема в организации. Самым правильным и наглядно полезным явилось бы создание БД по книжкам/журналам, возможно, документам для тех кому надо. Т.е., реализация очередного заброшенного мной проекта электронной библиотеки :))))
Это может быть и частью общей базы. Открываешь карточку, например, пилота и имеешь в отдельном поле БД ссылки на литературные источники.
СК
От Seeker
К SK (12.09.2006 15:59:08)
Дата 12.09.2006 21:18:16

Да..


>Это может быть и частью общей базы. Открываешь карточку, например, пилота и имеешь в отдельном поле БД ссылки на литературные источники.

Вот именно. Такую базу можно легко сопрячь с другими. Опять же, она может выступить пробным камнем, на ней можно обкатать все идею создания большой БД. Ну, а если глобальный проект провалиться - у нас будет база по источникам!
От Penio
К SK (11.09.2006 11:55:23)
Дата 12.09.2006 08:46:28

Ексел

Привет!

Если надо сделать базу данных, каторие состоятся от одна большая таблица лучше сделать на Ексел. Потом очень легко можно импортировать для все что нужно. А если нужно ее усложнять, может и в Екселе. Нет кокоята нужда о сложние СУБД.
От timsz
К Penio (12.09.2006 08:46:28)
Дата 12.09.2006 11:37:57

Думаю, там одной таблицей не обойтись.

Если систематизировать все факты получается скорее древовидная структура.

А в таблицу ее запихнуть сложно. В общем, поэтому реляционные СУБД не очень тут работают.
От Seeker
К SK (11.09.2006 11:55:23)
Дата 11.09.2006 18:28:05

Всеми руками и ногами - ЗА!

Давайте обсудим как все это чисто технически можно реализовать. Специалисты по информ. технологиям ждем вашего слова.

Мои дилетантские соображения (пара написанных БД еще в институте не в счет):
1. Надо делать не одну БД, а несколько связанных между собой. Т.е., отдельно с данными на личный состав, отдельно - с данными по самолетам, отдельно - по фотоснимкам. Тогда вместо одной громоздкой базы где большинство записей будут пусты, получим несколько более компактных и индексированных БД с возможностями поиска как внутри одной базы, так и в связанных с ней.

2. Формат - dbf, старенький, достаточно простой, поддерживается всеми СУБД.

3. Необходимо выработать какие данные собственно будут храниться в базе. Что жжизненно необходимо, а что излишество.

И вообще, если коллективно сформулировать ТТЗ на такую БД, полагаю, будет продуктивнее заказать ее реализацию како-нибудь софтверной конторе, чем заниматься самодеятельностью. Ведь главное - это содержание.

..
От SK
К Seeker (11.09.2006 18:28:05)
Дата 12.09.2006 11:19:14

Re: Всеми руками...

>Давайте обсудим как все это чисто технически можно реализовать. Специалисты по информ. технологиям ждем вашего слова.

>Мои дилетантские соображения (пара написанных БД еще в институте не в счет):
>1. Надо делать не одну БД, а несколько связанных между собой. Т.е., отдельно с данными на личный состав, отдельно - с данными по самолетам, отдельно - по фотоснимкам. Тогда вместо одной громоздкой базы где большинство записей будут пусты, получим несколько более компактных и индексированных БД с возможностями поиска как внутри одной базы, так и в связанных с ней.
Полностью согласен, но программа может быть и одной (если кто видел структуру, например, Бухгалтерии 1С, то пользоваться ею очень удобно, особенно при переходе из одного отчета в смежные)
>2. Формат - dbf, старенький, достаточно простой, поддерживается всеми СУБД.
Я тоже склоняюсь к этому формату.
>3. Необходимо выработать какие данные собственно будут храниться в базе. Что жжизненно необходимо, а что излишество.
Тут трудно говорить о необходимости. Уже сталкивался с проблемой, что гораздо позже приходится все равно для сравнения залезать и в "портянки", и в "расход пистолетных патронов". Нам это сейчас кажется не нужным, а какой-то другой исследователь параллельно роет именно эту тему. Пусть эта база и ему пригодится для работы (если чуть подстроить ее). А если среди своих папок он наткнется на "наш" документ, то занести в соответствующий раздел будет просто.
>И вообще, если коллективно сформулировать ТТЗ на такую БД, полагаю, будет продуктивнее заказать ее реализацию како-нибудь софтверной конторе, чем заниматься самодеятельностью. Ведь главное - это содержание.
О чем была просьба изначально. Определиться в наборе информации по отдельной части общей БД.
СК
От Seeker
К SK (12.09.2006 11:19:14)
Дата 12.09.2006 13:57:06

Далее...


>Полностью согласен, но программа может быть и одной (если кто видел структуру, например, Бухгалтерии 1С, то пользоваться ею очень удобно, особенно при переходе из одного отчета в смежные)

Программа, может и одна, но вот базы - разные. Опять же по программе - думаю имеет все же смысл сделать несколько, чтобы не плодить кучу невостребованных форм и отчетов.


>Тут трудно говорить о необходимости. Уже сталкивался с проблемой, что гораздо позже приходится все равно для сравнения залезать и в "портянки", и в "расход пистолетных патронов".

Так какие вопросы? Пусть создает новую БД, главное, чтобы были ясны и доступны механизмы ее интеграции в существующую структуру.

>О чем была просьба изначально. Определиться в наборе информации по отдельной части общей БД.

Как видно из обсуждения, весь пар уйдет в свисток. Поговорим, поговорим и забросим.
От igorGri
К SK (12.09.2006 11:19:14)
Дата 12.09.2006 11:47:35

А для пользования одной программой нужен координаторный пункт

Во превых - привести к общему знаменателю все переменные
Типа Фамилия - Строка, 26

Потом, какие данные и как заполняем. тут может еще пригодится типа такого, на человека заполнять несколько данных с сылкой на разный источник.

Значит сразу надо и источники приводить в общий вид..
От Seeker
К igorGri (12.09.2006 11:47:35)
Дата 12.09.2006 13:43:12

Абсолютно верно

>Во превых - привести к общему знаменателю все переменные
>Типа Фамилия - Строка, 26

Правильно, чтоб у "всех было ровно и одинаково", детали обговариваются. З.Ы. Вроде бы самая длинная фамилия в 34 символа, нет?

>Значит сразу надо и источники приводить в общий вид..

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

Но главная проблема - как организовать этот процесс. Скооперируемся - будет толк, а нет, ну тогда, как всегда, весь пар в свисток уйдет. До следующего поднятия этого вопроса...
От Hippo
К SK (11.09.2006 11:55:23)
Дата 11.09.2006 17:53:13

Re: База данных

>Приветствую уважаемых коллег!
>Хотел бы обратиься со следующей просьбой. Сейчас многие из нас создают различные базы данных (по потерям, по погибшим и т.д.) Я делаю свою по самолетам Як.
>В каком формате лучше всего делать базу, чтобы потом не пришлось со слезами на глазах перебивать все вручную (должна быть обеспечена возможность слияния баз данных).
>Второй вопрос, что необходимо бы включить в базу по самолетам кроме:
>типа, модификации;
>дат изготовления, приемки, потери, списания;
>серийного номера и завода изготовителя;
>мотора(ов) с № и на какую дату стоял на самолете;
>Движения самолета по полкам (прибыл, откуда, убыл, куда, источник, или дата и причина потери);
>состав вооружения и оборудования (просто какой из нескольких варантов или еще нужны номера);
>налет до потери;
>примечание.
>Надеюсь на помощь.
>СК

Прежде чем остановиться на Excel я перебрал неколько вариантов.
Для рабочей базы, учитывая возмоности сортировки, поиска ошибок и простоты обращения очень удобно.
Традиционные Базы данных все же предполагают "зашив" достоверной информации о сюжет.
И просто в тоску вгоняют плодящиеся эектронные книги Памяти.
НО это так личный опыт.
С уважением Hippo
От SDA
К Hippo (11.09.2006 17:53:13)
Дата 11.09.2006 19:57:20

Re: База данных

>Прежде чем остановиться на Excel я перебрал неколько вариантов...

По моему из "простого" куда лучше Access.

SDA
От SK
К SDA (11.09.2006 19:57:20)
Дата 12.09.2006 11:09:25

Re: База данных

>>Прежде чем остановиться на Excel я перебрал неколько вариантов...
>
>По моему из "простого" куда лучше Access.
Приветствую!
В данном формате моя база как раз и есть в настоящий момент. Но пользоваться им не очень удобно, как при формировании запросов, так и при изменении самих форм (таблиц) ввода. Плюс по мере набора информации "кирпич" базы растет ОДНИМ файлом, который "переворачивать" с каждым разом становится все дольше и дольше. Да и потерять этот один файл в результате сбоя или вируса довольно легко.
СК
От hunter019
К SK (12.09.2006 11:09:25)
Дата 13.09.2006 07:23:00

А ты периодически на компакт сохраняйся. (-)
От SK
К hunter019 (13.09.2006 07:23:00)
Дата 13.09.2006 11:01:46

Re: А ты...

Сам же знаешь, что после каждого сеанса это делать лень (спать хоцца), а на утро детишки притащили левый диск с игрушкой... Или просто поиграли немножко.
СК
От iShvedsky
К SK (13.09.2006 11:01:46)
Дата 13.09.2006 19:47:12

Re: А ты...

Добрый день!
>Сам же знаешь, что после каждого сеанса это делать лень (спать хоцца), а на утро детишки притащили левый диск с игрушкой... Или просто поиграли немножко.

Да в сети это всё должно быть. Типа Википедии.

---------------------
С уважением, iShvedsky
От Seeker
К SK (13.09.2006 11:01:46)
Дата 13.09.2006 11:34:47

Планировщик задач спасет вас :)) (-)
От Seeker
К SK (12.09.2006 11:09:25)
Дата 12.09.2006 13:29:37

SQL сервер рулит.. (-)