Здравствуйте всем.

Задался вопросом, что будет быстрее(лучше): хранить инфу в одной таблице в одном поле(строка 50-100 символов) и в дельфи разбивать на нужные данные по необходимости или создать 3-4(может больше) таблиц, и хранить в них уже разобранные строки?

delphi7, mssql2005.

Заранее благодарен.

Примечание. Хранил бы в одной таблице, но при разбиении строк получается разное количество подстрок.

> Задался вопросом, что будет быстрее(лучше):


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

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

Из этого следует, что мне лучше бы разбить на разные таблицы, чем заниматься работой со строками в дельфи?

> Из этого следует, что мне лучше бы разбить на разные таблицы,
>  чем заниматься работой со строками в дельфи?


Конечно.
Очень сильно подозреваю, что ты пытаешься решить проблему "многие-ко-многим" через задницу.

Я же не обозначил свои задачи, почему ты решил, что у меня "многие-ко-многим"?

> проблему "многие-ко-многим"

Даже если так, то почему это проблема?

> проблему "многие-ко-многим"

Даже если так, то почему это проблема?

Так обозначил бы задачу, тогда бы и подсказывать было проще и тебе полезнее!

> Я же не обозначил свои задачи, почему ты решил, что у меня
> "многие-ко-многим"?


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

А вообще megabyte прав - проблему уточни.

Спасибо, попытался описать проблему полностью - а это придётся структуру базы(хотя бы вкратце) описывать, в общем, я обломался это делать. )
По сути вопроса я в принципе понял - если в скуле всё нормализовать, то такой проблемы уже не возникнет, спасибо вам.

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


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

Я, собственно, почему про один-ко-многим тебя и спросил..  :)

Ну да, почти такая же мысль у меня возникла поначалу ;)
Только тут с абитурой, и несколько предметов у них.
Я так понимаю надо дополнительную таблицу просто - (ID, id_abiturienta, id_predmeta, ball) и все дела )

> Я так понимаю надо дополнительную таблицу просто - (ID,
> id_abiturienta, id_predmeta, ball) и все дела )


Правильно понимаешь.
Только вторичные ключи для целостности данных выставить не забудь.
И ещё: настоятельно не рекомендую использовать название столбца "ID". В большинстве случаев - зарезервированное слово.
Используй, например, "UNID" или "UID" (Unique Identifier).

> В большинстве случаев - зарезервированное слово.
это в каком сервере/движке? ни разу не встречал... т.е. это практически всегда незарезервированное слово.

> это в каком сервере/движке? ни разу не встречал... т.е.
> это практически всегда незарезервированное слово.


MSSQL. подсвечивает. Значит - резервированное. Может и неявно, типа как "at".

> MSSQL. подсвечивает


В каком, интересно, месте светит? :) MSE от 2005 Express не дает никакого особого света.

A IDE Index здесь зачем-то подсвечивает.
property Prop[Index: integer]: ...
И что?

> MSE от 2005 Express не дает никакого особого света.


Query analyzer - даёт

create table SomeTable
(
 [ID] int not null,
 [Name] varchar(32) not null,
 [Description] varchar(256) null

там до хрена этих "подсвеченных" слов. Что ж теперь - от всех отказываться?

> Что ж теперь - от всех отказываться?


Нет. Но это как с тем самым приснопамятным goto. Есть оператор? Есть. Можно использовать? Да, можно. Рекомендуется использовать? Ещё ни одной рекомендации не видел. Хотя пару раз сам использовал.

кстати, 2005 id уже не подсвечивает

> Ещё ни одной рекомендации не видел.
а я против использования ID. ни разу (в этой ветке не считается). подсветку в QA вроде видел, редко им пользуюсь, но даже если и видел то как то не обратил внимания.

> кстати, 2005 id уже не подсвечивает
исправили ошибку в "светильнике" или отказались от планов сделать зарезервированным. (если были такие)

at проверь

> at проверь


У меня 2005 нет. В QA из дистрибутива 2000 - подсвечивает.
Собственно, откуда заметил - была у меня табличка AnimationTemplates. Естественно, в качестве алиаса в конструкции from само-собой напрашивается AT. Вот и обратил внимание (даже года 2 назад ветку по этому поводу поднимал).

ID тоже подсвечивает.

> at проверь

не подсвечивает

> не подсвечивает


Ну когда я ветку поднимал, кто-то ссылку на microsoft давал, дескать это дело "на всякий пожарный" зарезервировано на будущее. Видимо в 2005-м передумали.

> clickmaker  (29.10.2008 12:40:18)  [18]

Не надо отказываться, просто надо использовать каноническую, а не сокращеную форму, Как приведено в кавычках, в соответствии с синтаксисом СУБД.

> sniknik  (29.10.2008 13:23:21)  [21]

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

> Ega23  (29.10.2008 13:45:23)  [23]

QA это свои понятия как подсвечивать, к резервированым словам не имеет отношения.