От Seeker
К timsz
Дата 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

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

Даже поудобнее будет.