0

I want to design a simple database management system like sqlite for my desktop application. Reason sqlite doesn't meet my need is it is not password-protected and not encrypted; open for anyone to view database using some kind of GUI app like Navicate.

In database design a record/tuple in the table should be indexed so that it can be searched fast for lookup /deletion /updation. As discussed here

These indexes use pointers to the records. Indexes can be dense, sparse, hash indexes etc. These indexes use pointers to the records in the database file. What these pointers points to-

  1. For performance reasons and efficiency no single record should span over two disk blocks as block is the smallest unit that can be read/writeen from disk. Using C file management API how can I know about disk blocks.
  2. Is the pointer in an index file is the a specific location where we can go using fseek() in a C language or a pointer to disk block?
stackOverflow
  • 179
  • 1
  • 2
  • 18

2 Answers2

0

  1. You haven't specified an OS, but on POSIX systems, you can the filesystem block size with statvfs(3).

  2. This sounds like an implementation detail of something that hasn't yet been written. But keep in mind, if your database is going to reside in a file, then you only have file-level abstractions to work with - meaning, file offsets are all you've got. You don't have access to the raw partition.

Also, have you looked into the SQLite Encryption Extension?

Jonathon Reinhart
  • 132,704
  • 33
  • 254
  • 328
0

Designing a good DBMS from the ground up is not a trivial task. And judging from your message, I seem you are not the person having enough knowledge to make it. It would be really better to find some ready implemenation which suits your needs. I believe it won't be too hard.

Now to your questions.

  1. No, a single record may span several disk blocks. The software implementation should not be too much dependent upon the hardware, and all HDDs have cache memory. All DBMS's have a logical unit called "page". The actual size of the "page" differs between implementations and user setup, so you'd better google on this subject yourself.

  2. Raw disk access is dangerous and tricky. You should avoid it, and leave to standard library as much as possible.

Matt
  • 13,674
  • 1
  • 18
  • 27