Легенда:
 новое сообщение
 закрытая нитка
 новое сообщение
 в закрытой нитке
 старое сообщение
|
- Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
- Новичкам также крайне полезно ознакомиться с данным документом.
Ответ всем сразу 02.11.03 04:47 Число просмотров: 1065
Автор: void <Grebnev Valery> Статус: Elderman
|
Отвечаю в корень всем сразу.
1) Спасибо, что обратили внимание.
2) Мне немного неудобно перед всеми за то, что задал вообщем-то дурацковатый вопрос.
Особенно неудобно перед «Лёшкой». Речь не идёт о локализации в нормальном для IT смысле этого слова. Ещё раз мои извинения, братцы.
Я подумал, что может «переписать» эту базу для нашей конторы. Сохранив при этом близкие сердцу министерцев обменные форматы данных.
Они (министерцы) говорят так: «Локально у себя (т.е. у нас) - вы можете использовать любое представление данных. Делайте, как хотите, если структура нашей базы (т.е. министерской) вас не устраивает. Вы (т.е. мы) обязаны сохранить совместимость на уровне выходных обменных форматов данных».
При этом под выходными обменными форматами они понимают целиком базу данных, упакованную в аксесовский файлик. Обмен весьма примитивен. По существу мы передаём в Москву не обновления – а целиком всю базу. Это их требование.
3) О том, на чём написано.
Министерцы написали всё в MS Access. Вернее они наняли проектировщиков из двух регионов России. Думаю, помыты не плохие бабки (упс., извините, товарищ майор, молчу). Нам отдали «as is» в аксесе. Сказали – юзайте (а мы - сказали ешь, значит ешь; сказали б не ешь- значит не ешь).
4) О том, зачем переписывать.
4.1) В сетевой многопользовательской среде – юзать это невозможно. Оно – не работает.
С некоторыми усилиями мы передвинули наш «локализованный» вариант базы на мелкомягкий сиквел. По крайней мере, наша публика в конторе теперь хоть работать может (сетевая обработка)
4.2) Клиентское ПО (язык не поворачивается его таковым называть) – оставили прежним – Access. Оно хм., гм.-гм.
Вот я и подумал – ежели уж переделывать, то надо б переделывать всё - и базу, и клиентскую прогу. Времени уйдет, думаю, месяца три, если писАть самому (не так уж и много).
5) О том, как можно было б переписать + мои пяти-копеешные около-аргументишки.
Можно было б "сгруппировать" справочные сущности, объединив их в несколько таблиц. А не 100 как сейчас.
Для различения последних (когда это необходимо, конечно) в клиетской проге - ввели бы дополнительное поле, где кодировалась бы сама "сущность". Т.е. район - code == 1, город - code == 2 и т.д.
АргуМенты
То, что у них.*************
Положим не каждую из таких таблиц для разных подзадач в клиентской проге
1) индекс для поля id
2) индекс для поля textval
3) индекс или индексы, гарантирующие уникальность id
4) индекс для защиты целостности ссылок по id
Итого на 100 таблиц 500 объектов
Если делать "группировку"*************
пусть в 20 таблиц с близкими понятиями (полезные ископаемые - к полезным, вся география к геогррафии и т.д. в простейшем случае)
1) Для всех таблиц - 100 индексов для защиты целостности ссылок
2) 20 индексов для поля id
3) 20 индексов для поля textval
4) 20 индексов для поля code
Итого на "справочную часть" имеем 180 объектов. И всё не хуже защищено. Надёжность и эффективность - выигрывают. Чем меньше объектов - тем лучше. Кроме того, есть подозрение и в части повышения "быстродействия" из-за страничной организации памяти при работе с таблицами MS SQL Server.
6) О том, почему я так делать не буду (т.е. я намерен оставить всё, как есть у министерцев, и ничего в их структуре не трогать).
Аргументы форумчан, а самое главное, то, что их высказали настоящие профи здесь, на форуме – это и есть аргумент для меня.
ПС.
Спасибо, братцы. Спасибо и за то, что не сказали сразу – ты… ну эта….. иди опохмелись вначале, а затем задавай вопросы.
|
|
|
подробно о проекте
Анализ криптографических сетевых...
