Мастера DELPHI (документация, исходники, скачать)

Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / RSDN.ORG

« предыдущая ветвь | форум | следующая ветвь »

Таблица из текстового файла [D7]

Страницы: < 1 2 3 4 >
Xmen © (2008-11-28 16:01:00)
Привет мастерам!
У меня такой случае. Нужно использовать текстовый файл как базу, то есть в программе нужно использовать справочники с элементами таблицы. Записи обычно 20 - 25 шт, иногда нужно их освежить (удалить, редактировать, добавить). Для этого я бы не хотел использовать какое то СУБД, а воспользоваться простым текстовым файлом. В каком направление посоветуете мне работать.

Anatoly Podgoretsky (2008-12-03 18:44:00) [21]
> clickmaker (03.12.2008 17:13:45) [45]

Не знаю, может для совместимости с SmallInt
Я не вдавался в подробности, я просто использую базу.

clickmaker (2008-12-03 17:13:00) [22]
> как nvarchar(127)

а почему не 128?

Anatoly Podgoretsky (2008-12-03 17:04:00) [23]
> MsGuns (03.12.2008 16:44:43) [43]

> Третье.
> Некоторые "нативные" характеристики (МФО, ИНН, Расчетные счета, Налоговые номера и т.д.), которые якобы числовые, следует определять стрингами достаточной длины.

Поскольку это не числа и операции над ними совсем другие.
Насчет достаточной длины - ее надо умножить на 3 как минимум, а то завтра окажется, что недостаточно
У меня, не в моей базе, все подобные права объявлены как nvarchar(127)

MsGuns (2008-12-03 16:44:00) [24]
Замечания к (36)

Первое.
До каких бы то ни было манипуляций с сервером (создания таблиц и пр.) надо НАРИСОВАТЬ модель базы. Т.е. определить ОБЪЕКТЫ и их СВОЙСТВА (характеристики). Затем нарисовать между ними связи. Уже по рисунку будет видно ОБЩЕЕ между объектами, которое затем будет использовано при НОРМАЛИЗАЦИИ, т.е. придание характеристкам АТОМАРНОСТИ, а также устранение ИЗБЫТОЧНОСТИ. По этой же схеме будет видно, какие характеристики являются ОСНОВНЫМИ, вводимыми непосредственно с документов или иных внешних источников, а какие РАСЧЕТНЫМИ или СЛУЖЕБНЫМИ, т.е. вычисляемыми или используемыми программно.

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

Третье.
Некоторые "нативные" характеристики (МФО, ИНН, Расчетные счета, Налоговые номера и т.д.), которые якобы числовые, следует определять стрингами достаточной длины. На клиенте Вы можете отображать и проверять каждое из них как угодно, но вот закладывать это ограничение на сервер не следует. Хотя бы потому, что у Вас будут проблемы с ведущими нулями, которые будут "съедаться" при операциях сравнения, искажая результат.

Четвертое.
При определении типа дробных характеристик (суммовые, количественные и т.д.) рекомендую указывать дробь с "запасом" даже если это на первый взгляд не требуется. Жизнь показывает, сто в какой-то момент потребуется уточненный учет и Вам придется мерять структуру таблиц, если не бизнес-логику впридачу

Что такое структура приложения в Вашем понимании - не совсем ясно :)

Anatoly Podgoretsky (2008-12-03 16:31:00) [25]
> Xmen (03.12.2008 16:02:40) [40]

А что будешь делать, если завтра станут 10 значные.

Сергей М. (2008-12-03 16:17:00) [26]

> У нас ИНН 7 значные

Это где, на о.Борнео ?

Xmen (2008-12-03 16:02:00) [27]
У нас ИНН 7 значные

Anatoly Podgoretsky (2008-12-03 13:54:00) [28]

> INN может не влезть в integer (там же 12 цифр, насколько
> я знаю)

INN это не число, а код, поэтому никаких числовых типов.

Сергей М. (2008-12-03 13:28:00) [29]

> PL_SUM_WORD

Вот эту хрень сразу убирай - никому в базе она не нужна

clickmaker (2008-12-03 13:26:00) [30]
> CL_

это лишнее. Зачем усложнять?

> CL_ID

лучше CLIENT_ID

INN может не влезть в integer (там же 12 цифр, насколько я знаю)

Xmen (2008-12-03 13:17:00) [31]
Пока сдела 2 таблицы.

CREATE TABLE CLIENTS (
ID INTEGER NOT NULL,
CL_NAME VARCHAR(150),
CL_ACC CHAR(20),
CL_BANK_CODE INTEGER,
CL_BANK_NAME VARCHAR(150),
CL_OKONX INTEGER,
CL_INN INTEGER
);

ALTER TABLE CLIENTS ADD CONSTRAINT PK_CLIENTS PRIMARY KEY (ID);

CREATE TABLE PLATEJKA (
ID INTEGER NOT NULL,
CL_ID INTEGER,
PL_NUM INTEGER,
PL_DATE DATE,
PL_SUMMA NUMERIC(15,2),
PL_SUM_WORD VARCHAR(200),
PL_PUR_PAY VARCHAR(200)
);
Сделал толко одну табицу справочника.

>как правильно организовать структуру программы?
Я и самой проги хотел спросить.

MsGuns (2008-12-03 12:40:00) [32]
>Xmen (03.12.08 10:29) [32]
>как правильно организовать структуру программы?

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

Сергей М. (2008-12-03 10:59:00) [33]

> Xmen

Если ты на время откажешься от затеи с FB и задействуешь TClientDataset, решив тем самы проблему с контейнером простейшим и очевиднейшим способом, то впоследствии заменить файловый контейнер на FB будет очень просто, без радикальной переделки программы : вместо LoadFromFile - Open, вместо SaveToFile - ApplyUpdates

Sergey13 (2008-12-03 10:54:00) [34]
> [32] Xmen (03.12.08 10:29)
> И так новый вопрос как правильно организовать структуру
> программы?

читать умеешь?

> [26] MsGuns © (01.12.08 14:47)

Xmen (2008-12-03 10:29:00) [35]
Спасибо за советы я уже начал работат с базой FB. Долго думал после ваших советов и решил нужно всетаки сделать полноценную прогу или хотябы похоже нанего. И так новый вопрос как правильно организовать структуру программы?

Loginov Dmitry (2008-12-01 22:31:00) [36]
> А клиентов штук 10 - 15. Для 15 строк не хочется беспокоить
> FB

Это одних только клиентов 15 шт! А организация, которой предназначена эта прога, вероятно будет регулярно оформлять платежи тем или иным клиентам. В день по платежу, это уже 300 документов, а никак не 15 строк!!! А за FB не нужно беспокоиться, это инструмент как раз и предназначен для хранения всевозможных данных, в том числе и "15 строк клиентов".

> Тебе нужен Эксель.
> Он самодостаточен для данной работы.

+1)

Anatoly Podgoretsky (2008-12-01 16:02:00) [37]
> Xmen (01.12.2008 15:25:28) [28]

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

Сергей М. (2008-12-01 15:39:00) [38]

> как правильно использовать его?

Используй его как любой другой наследник TDataSet.
Основная разница в том, что открытие НД происходит при вызове CreateDataset (создается пустой НД заданной тобой структуры) или при вызове LoadFromFile (готовая структура НД вместе с самими ранее сохраненными методом SaveToFile данными грузится из указанного файла)

Xmen (2008-12-01 15:25:00) [39]
Я сам в проектах использую FB - мой любимый СУБД.
У меня в справочнике будет толка один файл с информации.
Имя клиенте, р/с,код банка, МФО банка, имя банка, оконх, инн и все в одной строки. А клиентов штук 10 - 15. Для 15 строк не хочется беспокоить FB. А так мне легче было бы его использовать. Мне понравилось предложение насчет TClientDataSet. И как правильно использовать его? Немножко примера не помешаеть мне.

clickmaker (2008-12-01 14:57:00) [40]
> я бы нехотел исползовать пушку. Мне для этого достаточно
> перочиного ножа

так а embedded - это и есть что-то типа перочинного ножа
пушка - это ms sql или оракл

Страницы: < 1 2 3 4 >

Наверх

	« предыдущая ветвь \| форум \| следующая ветвь »