Сам никогда не сталкивался с подобной проблемой, но вообще интересно.
Решение задачи конечно зависит от того ЧТО (лог.модель) за объекты предполагается хранить и какие МАНИПУЛЯЦИИ (физ.модель) с ними будут осуществляться. Нельзя ли по-подробнее обрисовать?

2 Cat2:
Тут как-то один человек делал картографию. Ему оказалось наиболее удобным хранить координаты в виде строк, в которых через запятую перечислялись числа.

Да, я помню интересная тема была: что-то связанное с транспортной доставкой, необходимо было по введенной улице вычислять расстояние или вычислять оптимальный маршрут до места назначения по разным метрикам (километраж, качество покрытия дороги, число постов ГИБДД и тд). А у Вас ссылки случайно не сохранилось на ту дискуссию? Буду премного благодарен! ;)

2 wara:
Ну а простым ребятам где лучше графику хранить?

Эта тема обсуждалась (даже не однократно) в разделе MSSQL. Поиск в форуме ничего не дал что ли?
Основные аспекты по растровой графике если 2-х словах:

* Если клиент оперирует только с цельными изображениями, например, web-клиент, то удобнее и быстрее (доказано тестированием) хранить в БД URL-ссылки или физические пути (varchar) на файлы изображений. На многих web-серверах так и делается
* Если необходима очень быстрая и точная (т.е взять конец или начало картинки, или например кусок видеоряда в диапазоне) работа с изображениями, а также хочется получить фичи, предоставляемые БД (поиск, сравнение BLOBов, блокировки и тд) и когда сложности обслуживания (т.е сырые партиции, RAID) и стоимость оборудования не имеют особого смысла, то тогда имеет смысл хранить сами изображения в БД (image). Обычно так делается в профессиональных студиях монтажа, например, в Голливуде где оцифрованное видео хранится на Informix и Oracle

2 Annv:
Предполагается хранить объекты типа сфера, линия, которые образуют опредленную сцену. Эти объекты могут быть заряженными

А множество возможных объектов в сцене конечно? От этого зависят все дальнейшие рассуждения.
Вообще IMHO для подобных целей отлично подходят т.н истиннообъектные СУБД типа IS Cache' (а не ОРСУБД типа Informix или Postgres) - т.е задача, например, свелась бы просто к определению каких-то базовых классов и их типов, и уже на основе их можно было бы создавать любое геометрическое многообразие объектов, инициализировать и ассоциировать их как угодно, а также хранить в БД. Тем более, что Cache работает без ограничений с 1-пользовательской лицензией

2 Annv:
Дело все в том что объекты нужно хранить в Access . А набор объектов естественно конечен .

ОК, основные ограничения ясны :) Но можно все таки по-подробнее об объектах?

2 wara: \r
Репликант, спасибо за разъяснения, до MSSQL я пока "не дорос", поэтому и не искал ничего в их форуме. \r
\r
Всегда пожалуйста :) Я тоже непосредственным программированием на TSQL мало уже занимаюсь, но все равно там вопросы/топики интересные встречаются (то же Междумордие) поэтому лучше этот форум "мониторить" хотя бы периодически\r
\r
Прошу прощения, если что неграмотно скажу, вот только я думаю, что то, как и что хранить в Access (графические примитивы), зависит от того, какая система затем будет эти данные использовать. \r
\r
Ну дык, конечно! Только вот человек что-то молчит по этому поводу :(\r
\r
Ведь интересно потом по этой базе и картинку увидеть, а не просто данные хранить. Значит нужен некий драйвер, который потом данные базы затем преобразует к виду, который "поймет" графическая программа. \r
\r
Да, но только это уже архитектурные особенности, а тут еще даже модели данных как бы и нет\r
\r
В одной моей базе, к примеру, хранились данные о продукции, которая характеризовалась след параметрами :плоский "профиль" (задается координатами точек, последовательно рисующих профиль начиная с левого угла по часовой стрелке) и диаметр (перпендикулярен оси вращения профиля).... \r
\r
Все правильно - предметная математика также определяет модель данных, к-рая должна полноценно описывать объекты этой предметной области

2 Annv:
Я не молчу, а говорю что данные которые будут храниться будут затем визуализированы с помощью OpenGL.

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

2 Annv:
Я не знаю как вам описать эти требования, может для примера спросите что-нибудь из подразумеваемых требований.

Т.е это не совсем требования, это вопросы, ответы на к-рые и могут являться требованиями:

1. Число возможных видов объектов конечно, но сколько видов объектов всего может быть
и что это за виды?
Например, возможные виды: линии, дуги, плоскости, параллепипеды, цилиндры, сферы и конусы.
2. Каковы основные характеристики видов объектов (и для чего они нужны)?
Например, основные характерстики - это только их геометрические характеристики, к-рые определяют
только формы и например позволяют построить некую начальную сцену
3. Каковы дополнительные характеристики видов объектов (и для чего они нужны)?
Например, дополнительные характеристики - это также какие-то физические характеристики:
электрический заряд, проводящая способность (металл, диэлектрик) и т.д, к-рые определяют,
например, распределение эл.статического поля и позволяют построить вам некую окончательную сцену

2 Annv:
1. Число объектов сцены естественно конечно: объектами могут быть линии, плоскости, цилиндры, сферы, параллелепипеды, ну а вообще любые поверхности.

"ну а вообще любые поверхности" - т.е что абсолютно любые любых порядков что ли?

2. Характеристиками объектов являются естественно их геометрические характеристики (для построения) + доп. характеристики - напряженность эл. поля, потенциал этого поля.

С электростатикой я давно обчался поэтому простите за ламерский вопрос - что первично: потенциал (вполне определенная величина для объекта) или напряженность поля, распределение к-рой вообще зависит от формы, потенциала и растояния от объекта?

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

В смысле "взаимосвязи"?